GAWK 3.1.1 numeric typing bugs

[Serge Bohdjalian]

Hi Stephan,

Thanks for your detailed response.

At 2003.01.08 10:27 AM +0100, you wrote:
> Would you mind if I forwarded it to bug-gawk
> (alias bug-gnu-utils)
> discussion list so that it gets archived, and people can find it 
> via
> web searching engines?

Feel free to forward any of our e-mails.

> You can also forward your previous mail, so
> that the thread is complete.
> What do you think?

Sure. Forgive my ignorance, but how do I do that? Do I just forward the
e-mail to address@hidden?

> Unfortunately, you tripped over a bug here (in
> fact, double bug).
> The two bugs hiding each other, in combination with the fact that
> you
> was not aware that assigning a field is completely different from
> getting it from input file have to confuse you.
> I hope it's clearer now.

I think I get it now. In sum, for the following script and 
output...

BEGIN {
   $0 = "0";
   if ($0) print $0 " = TRUE"; else print $0 " =
FALSE";
   $0 = "0e0";
   if ($0) print $0 " = TRUE"; else print $0 " =
FALSE";
   a = "0";
   if (a) print a " = TRUE"; else print a " =
FALSE";
   a = "0e0";
   if (a) print a " = TRUE"; else print a " =
FALSE";
}

C:\TEST>"C:\TEST\gawk310_SourceForge.exe" -f
"TEST.AWK" "TEST.TXT"
0 = FALSE
0e0 = TRUE
0 = TRUE
0e0 = TRUE

C:\TEST>"C:\TEST\gawk311_Cygwin.exe" -f "TEST.AWK"
"TEST.TXT"
0 = FALSE
0e0 = TRUE
0 = TRUE
0e0 = TRUE

C:\TEST>"C:\TEST\gawk311_DJGPP.exe" -f "TEST.AWK"
"TEST.TXT"
0 = FALSE
0e0 = FALSE
0 = TRUE
0e0 = TRUE

...the result should be "TRUE" in all cases. The result of the
first _expression_ is wrong with all 3 versions of GAWK (for Windows) used
above, and there's a "double bug", as you say, in the DJGPP
version of GAWK because the result it gives for the second _expression_ is
also wrong.

A final note: in "normal" awk program you don't enter into this.
The source could probably contain not only 00EF but also 0089 which
would be interpreted as (decimal) number.  So the usual way is to
ensure that the value is string, like this:

        a = $2 ""

I "tripped" over these bugs because I was processing
hexadecimal string input (e.g., "00EO") and evaluating whether
a string was found. I was using an _expression_ like...

   if (a) {

This was concise, "C-like", and appeared to be more efficient.
I realize now that this is a bad practice because if the string is a
"strnum" that can be interpreted as zero (e.g.,
"00EO"), such an _expression_ will return a "FALSE" (0)
value. I've since revised all my code so that such empty string tests are
written like...

   if (a != "") {

Concatenating an empty string to the possible "strnum" will
also do the job and, in certain cases, may be more appropriate (e.g.,
where there's one assignment to that string but many expressions using
that string). In some cases, concatenating an empty string may be the
only option (e.g., comparing 2 possible "strnum" variables).
However, in tests that I've run, this may also be slower if all you want
to do is test for an empty string.

Thanks again for your help.

-Serge