[Top][All Lists]

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

Re: [bug-gawk] gawk erroneous comparison with large negative exponents

From: Aharon Robbins
Subject: Re: [bug-gawk] gawk erroneous comparison with large negative exponents
Date: Thu, 16 Apr 2015 13:23:30 +0300
User-agent: Heirloom mailx 12.5 6/20/10

Hi Andy.

> Oops -- that was not the correct patch.  I think the correct patch
> is attached.  If that looks good, I can push it.

It looks good to me. Please pull & merge and then push to gawk-4.1-stable
and from thence merge to master.

> But I must confess that I'm a bit confused about the flag usage.
> The problem with the previous patch was that values where the leading
> part is numeric should ignore trailing alpha junk.  So "3D" should be
> converted to a numeric value of 3.  When that conversion occurs, why do
> we not set the NUMCUR flag?

We do. I don't understand your question.

> Also, the comment next to the NUMBER flag sets "assigned as number",
> so we does r_force_number enable this flag?

It doesn't, not anywhere that I can use. It uses NUMCUR everywhere.

> It seems to me that r_force_number
> can be called when it was not actually assigned as a number.  I'm
> interpreting "assigned as number" to mean something like
>    x = 3
> Is that not what it means?

Yes, but r_force_number uses NUMCUR, not NUMBER.

> Also, should we not have a more explicit test that values with trailing
> non-numeric stuff accept leading numeric values?  Finding such a problem only
> through the array-sorting test seems a bit indirect...

I don't think there's any real problem.

Can you show a real test case that shows a problem? In particular where
gawk is different from BWK awk and/or mawk?

        $ git branch
        * gawk-4.1-stable
        $ ./gawk 'BEGIN { x = "3 and a half" ; print x + 2 }'



reply via email to

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