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

[arnold]

Hi. I looked at this some more.

Steven Penny <address@hidden> wrote:

> Tested with Gawk 4.2.1 and 4.1.4. Hex literals work as expected:
>
>     $ awk 'BEGIN {print 0x21}'
>     33
>
>     $ awk --posix 'BEGIN {print 0x21}'
>     0

These are fine.

> However when converting from string to hex literal, you get the opposite
> of what is supposed to happen:
>
>     $ awk 'BEGIN {print +"0x21"}'
>     0

This is correct.

>     $ awk --posix 'BEGIN {print +"0x21"}'
>     33

This is also correct.

Explanation:

The expression +"0x21" means "take the string value given, convert it
to a number, then apply unary + to it" (effectively a no-op).  It is
absolutely the same, semantically, as something like

        { print +$1 }

The documentation describes that when working on *data*, numeric values
not in decimal are _not_ treated specially, since this goes against historical
practice and can lead to surprising results. You have to use the
--non-decimal-data option if you really want such behavior.

Thus the first case stops after the '0' and treats the numeric value
as zero.

The --posix case is different.  Here, gawk follows the standard which
says that awk calls strtod(3).  The problem is that in C99 strotod
recognizes non-decimal bases and converts them, a change from C89 and
earlier POSIX.  I've tried in the past to get this fixed in POSIX
but haven't succeeded.

See 
https://www.gnu.org/software/gawk/manual/html_node/POSIX-Floating-Point-Problems.html#POSIX-Floating-Point-Problems
for some more discussion.

Thanks,

Arnold