bug-gawk
[Top][All Lists]
Advanced

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

Re: [bug-gawk] Invalid result when converting to hex literal


From: arnold
Subject: Re: [bug-gawk] Invalid result when converting to hex literal
Date: Wed, 21 Mar 2018 01:37:49 -0600
User-agent: Heirloom mailx 12.4 7/29/08

Hi Nelson.

"Nelson H. F. Beebe" <address@hidden> wrote:

> However, hexadecimal floating-point constants were introduced into C99
> for an extremely important reason: they allow exact specification of
> floating-point bit patterns that could not be reliably obtained with
> either decimal input, or with C library function calls, or with
> recognizable rational numbers, because there is no guarantee that I/O
> base conversions, and library functions, and floating-point division,
> always produce correctly-rounded results.

That's all fine and good. But awk is not C, nor does it aim to be.
I would further suggest that awk is not a language to use for serious
numerical work in any case.

>     Hexadecimal floating point is not supported (unless you also use
>      '--non-decimal-data', which is _not_ recommended).

This is talking about *DATA*, not constants in the source code.

        $ echo 0x2A | gawk '{ print $1 + 0 }'
        0
        $ echo 0x2A | gawk --non-decimal-data '{ print $1 + 0 }'
        42

> Let us try the latter suggestion with gawk-4.2.1:
>
>       % gawk --non-decimal-data 'BEGIN {print 0x1p5}'
>       1

You are assuming that gawk knows how to parse C99 floating point
hex constants. It doesn't. It only understands C89 format hex values.

Even with --non-decimal-data, gawk does not currently understand
C99 floating point hex values, since it does not use strtod for
this conversion.  Changing this is something that I may consider,
but it would be only in the context of the --non-decimal-data option.

> At least the three major awk implementations behave consistently: they
> all ignore nonnumeric suffixes without raising an error, and silently
> skip to the next recognizable lexical token:
>
>       % gawk 'BEGIN {print 12345foolish}'
>       12345

Here you are way out in left field. This is printing the string concatenation
of 12345 with the value of variable named "foolish". Since variables are
auto-initialized to the null string, all you're getting is the 12345. This
is easy to prove:

        $ gawk -v foolish=fooled 'BEGIN { print 12345foolish }'
        12345fooled

In short, gawk purposely ignores C99 hex floating point.

It may be time to reconsider this decision, but then again, it may not.

Thanks,

Arnold



reply via email to

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