bug-gawk
[Top][All Lists]
Advanced

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

Re: [bug-gawk] gawk bug: IGNORECASE=0 does not work


From: Andrew J. Schorr
Subject: Re: [bug-gawk] gawk bug: IGNORECASE=0 does not work
Date: Mon, 2 Feb 2015 08:18:04 -0500
User-agent: Mutt/1.5.23 (2014-03-12)

Hi,

On Fri, Jan 30, 2015 at 03:00:23AM -0500, Jeff B wrote:
> # We explicitly set IGNORECASE to *ZERO* and, huh?  This should not match.
> qbarry $?=0> gawk -v IGNORECASE=0 '
>   BEGIN { if ( "a" == "A" ) print "match"; else print "no match" }'
> match

This does appear to be a bug.  In eval.c:set_IGNORECASE, the problem is here:

        NODE *n = IGNORECASE_node->var_value;
        ...
        if (do_traditional)
                IGNORECASE = false;
        else if ((n->flags & (STRING|STRCUR)) != 0) {
                if ((n->flags & MAYBE_NUM) == 0) {
                        (void) force_string(n);
>>>                     IGNORECASE = (n->stlen > 0);     <<<
                } else {
                        (void) force_number(n);
                        IGNORECASE = ! iszero(n);
                }
        } else if ((n->flags & (NUMCUR|NUMBER)) != 0)
                IGNORECASE = ! iszero(n);
        else
                IGNORECASE = false;             /* shouldn't happen */


In this test case, the value is set by the line marked by ">>> ... <<<".
The flags have STRING or STRCUR set, but not MAYBE_NUM.  It's not immediately
obvious to me whether there's a logic bug here, or if the problem is that
MAYBE_NUM is not set for a value set on the command line with -v.

Note that this version works properly:

bash-4.2$ gawk 'BEGIN { IGNORECASE = 0; if ( "a" == "A" ) print "match"; else 
print "no match" }'
no match

As does this:

bash-4.2$ echo 0 | gawk '{ IGNORECASE = $1; if ( "a" == "A" ) print "match"; 
else print "no match" }'
no match

But this one also fails:

bash-4.2$ gawk 'BEGIN { IGNORECASE = "0"; if ( "a" == "A" ) print "match"; else 
print "no match" }'
match

Perhaps the MAYBE_NUM test is too stringent -- a string value of "0" seems worth
interpreting as a number, if not too challenging.  Maybe there are 2 bugs here.

On the other hand, the code in main.c:arg_assign appears to set the MAYBE_NUM 
flag,
so I'm a bit confused about what's going on.  Further debugging is required...

Regards,
Andy



reply via email to

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