Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

HUGE_VAL

5 views
Skip to first unread message

Thomas Koenig

unread,
Jan 27, 1997, 3:00:00 AM1/27/97
to

I'm a bit confused about HUGE_VAL.

Is a strictly conforming program allowed to

- assign it to a variable?

- print it out with printf()?

- read back the value printed out previously with scanf()?

Paul Eggert

unread,
Jan 27, 1997, 3:00:00 AM1/27/97
to

ig...@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes:

> Is a strictly conforming program allowed to
> - assign it to a variable?

Yes.

> - print it out with printf()?

No, because a strictly conforming program can't depend on any
implementation-defined behavior.

Typical implementations print `Inf' or `Infinity' here.
Unfortunately this behavior can be locale-specific.

> - read back the value printed out previously with scanf()?

No. And in practice, many `scanf' implementatations do not parse `Inf'
or `Infinity' as one might expect.

I hope this area gets fixed up in the C9X effort.
It should always be possible to read a number that you printed,
at least if your locale settings are the same.

Thomas Koenig

unread,
Jan 28, 1997, 3:00:00 AM1/28/97
to

In comp.std.c, egg...@twinsun.com (Paul Eggert) wrote:

[HUGE_VAL]

>ig...@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes:
>> - print it out with printf()?
>
>No, because a strictly conforming program can't depend on any
>implementation-defined behavior.

In 7.5, it says

[...]

# The macro defined is
#
# HUGE_VAL
#
# which expands to a postitive double expression, not necessarily
# representable as a float.

I don't find anything about HUGE_VAL not being printable with
printf(), and also no mention of implementation-defined behaviour,
except in the footnotes, which mention infinity.

>Typical implementations print `Inf' or `Infinity' here.
>Unfortunately this behavior can be locale-specific.

I don't doubt that you describe typical behaviour of existing
implementations; I'd be interested, however, wether or not
this behaviour is broken WRT the C standard.


Paul Eggert

unread,
Jan 28, 1997, 3:00:00 AM1/28/97
to

ig...@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes:

>>Typical implementations print `Inf' or `Infinity' here.
>>Unfortunately this behavior can be locale-specific.

>I don't doubt that you describe typical behaviour of existing
>implementations; I'd be interested, however, wether or not
>this behaviour is broken WRT the C standard.

It's not broken. Commentary on the standard mentions this possibility;
it's in a footnote, if I recall correctly.

Besides, no other behavior make sense. It would be silly to define
HUGE_VAL to a value other than infinity; and it would be equally silly
to print infinity as "1e999" or something like that, since it wouldn't
be read in correctly into a host that could actually represent 1e999.
On IEEE hosts, HUGE_VAL should print as something that is not an
ordinary number. (Perhaps it could be printed "HUGE_VAL". :-)

Thad Smith

unread,
Jan 28, 1997, 3:00:00 AM1/28/97
to

In article <5clftf$o72$1...@shade.twinsun.com>,

egg...@twinsun.com (Paul Eggert) wrote:
>ig...@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes:
>
>>>Typical implementations print `Inf' or `Infinity' here.
>>>Unfortunately this behavior can be locale-specific.

>... no other behavior make sense. It would be silly to define


>HUGE_VAL to a value other than infinity; and it would be equally silly
>to print infinity as "1e999" or something like that, since it wouldn't
>be read in correctly into a host that could actually represent 1e999.

The floating point types are not required to have a representation of
infinity. If not, HUGE_VAL is a finite value and can be formatted
normally.

>On IEEE hosts, HUGE_VAL should print as something that is not an
>ordinary number. (Perhaps it could be printed "HUGE_VAL". :-)

I agree. Perhaps the proposed numeric extensions address this issue.

Thad

0 new messages