bug-gawk
[Top][All Lists]
Advanced

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

Re: [bug-gawk] Bug: invalid evaluation of variable in for statement


From: david kerns
Subject: Re: [bug-gawk] Bug: invalid evaluation of variable in for statement
Date: Wed, 3 Feb 2016 06:47:32 -0700

I'm saying awk has very loose (think no) typing. Every variable is either (both and, not either or) a string or a number, and the only way you can be certain the correct form of comparison is used is by turning the variable into an _expression_ as part of the comparison:

a = "3.0";
b = 3.0;
if (a + 0 == b) { print "I am certain this is true" }
if (a != b "") { print "I am certain this true, do you see why?" }
# this will show:
print a + 0, a ""
print b + 0, b ""

from the man page:

There are no explicit conversions between numbers and strings.  To force an _expression_ to be treated as a number add  0 to it; to force it to be treated as a string concatenate "" to it.

Why you have behavior changes between 3.x and 4.0.1 I'm sure can be (eventually) answered by this mail-list, but would still fail to be considered a bug.


On Tue, Feb 2, 2016 at 11:34 PM, Wolfgang Laun <address@hidden> wrote:
David,

So you are saying that even if a statement like this:
     if( hashsizes[hsidx] == +10 ){
        print hashsizes[hsidx] " == 10";
     } else if( hashsizes[hsidx] == 13.0 ){
        print hashsizes[hsidx] " == 13";
     }
preceding the for loop and printing 10 == 10 and 13 == 13 one must not rely on the obvious assertion? And reckon that an operator like '<' does not do a numeric comparison? Is there any rule that says that evaluation is different for '==' and '>'?

Also, I've been trying hard (but failing) to understand the GAWK manual, Subsection 6.3.2.1, String Type versus Numeric Type, in the light of how GAWK 4.x is behaving in my sample code.

Finally, is there an explanation why the behaviour changed between 3.x and 4.0.1?

Cheers
Wolfgang





On 2 February 2016 at 23:22, david kerns <address@hidden> wrote:
I'd be hard pressed to call this a bug. While awk tries to do the right thing, if you the programmer know you need a specific evaluation (number vs string) you're supposed to add 0 or concat a "" appropriately.

Sent from my iPhone

> On Feb 2, 2016, at 12:07 PM, Wolfgang Laun <address@hidden> wrote:
>
> Since searches like  "evaluation and variable and for statement" didn't turn up anything, I may have found a new bug in GNU Awk 4.0.1.
>
> A for statement like the one below doesn't work correctly:
>    for( i=0; i < hashsizes[hsidx]; i++ ){
>
> After adding "+0" to the upper limit, it works fine. The code has worked fine for years, using GNU Awk 3.x. Below is the full program to demonstrate the problem.
>
> Regards
> Wolfgang
>
> function demo( ) {
>     print "demo";
>     split("", tosigarr);    # init
>     tosigarr[1] = 12;
>     tosigarr[2] = 23;
>     nsig = 2;
>
>     tohsizeparam = "10v,13s";
>     gsub( / /, "", tohsizeparam );
>     hsnr = split(tohsizeparam, hashsizes, ",");
>     for( hsidx=1; hsidx <= hsnr; hsidx++ ){
>
>         gsub(/[^0-9]*$/, "", hashsizes[hsidx]);
>
>         print "hashsizes[" hsidx "]=" hashsizes[hsidx] "!";
>
>         split("", tosighash);    # init
>         for( idx=1; idx <= nsig; idx++ ) {
>             h = tosigarr[idx] % hashsizes[hsidx];
>             tosighash[h] = "" tosighash[h] tosigarr[idx] " ";
>         }
>
>         print "hashsizes[" hsidx "]=" (hashsizes[hsidx]+1) "!";
>
> ### need to force conversion to number for the loop to work correctly
>     for( i=0; i < hashsizes[hsidx]; i++ ){
> ###    for( i=0; i < hashsizes[hsidx] + 0; i++ ){
>         if( i in tosighash ) {
>         hstr = hstr "  " tosighash[i] ",\n";
>         hused++;
>         } else {
>         hstr = hstr "  -1,\n";
>         }
>     }
>         print hstr;
>     }
> }
>
> BEGIN {
>     demo();
> }
>



reply via email to

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