[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gawk infinity issues

From: Andrew J. Schorr
Subject: Re: gawk infinity issues
Date: Fri, 6 Jan 2006 10:38:05 -0500
User-agent: Mutt/1.4.1i

On Fri, Jan 06, 2006 at 09:51:34AM -0500, Andrew J. Schorr wrote:
> The Open Group awk specification at 
>    http://www.opengroup.org/onlinepubs/009695399/utilities/awk.html
> says:
>    A string value shall be converted to a numeric value by the equivalent of
>    the following calls to functions defined by the ISO C standard:
>    setlocale(LC_NUMERIC, "");
>    numeric_value = atof(string_value);

Looking back in the archives, I see that there have been disagreements
in the past over whether awk should behave the same way as atof (or strtod).
But the discussion there seemed to be about whether hexadecimal floating-point
values should be accepted.  I don't want to re-open that can of worms,
but the question here is whether NaN or Infinity values should be accepted.

Based on the previous discussion, I would have imagined that the
pseudo-algorithm should be something like: if it looks like a hexadecimal
floating-point value, then do not accept it, otherwise call strtod.  But it
seems that the current code in force_number will call strtod for a string that
looks like "-nan" or "-inf", but not for "nan" or "inf" (since there is an
ISALPHA test on the first character of the string).  And whether the -nan or
-inf is interpreted correctly depends on whether gawk_strtod is being used
(since gawk_strtod does not accept nan or inf values).  So my question
is why not rewrite force_number to call strtod unless the string looks
like one of the hexadecimal values that we want to exclude?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]