Re: bin/48017: awk(1) fails to treat var as integer (may be related to #47840)

[David Holland <dholland-bugs%netbsd.org@localhost>]

On Wed, Jul 10, 2013 at 08:55:01AM +0000, Steffen Daode Nurpmeso wrote:
 >  David Holland <dholland-bugs%netbsd.org@localhost> wrote:
 >   | sprintf witih %d doesn't produce an number value; it produces a
 >   | string value, which you have to coerce to a number by adding zero to
 >   | it to get it to behave like a number.
 >  
 >  (Adding +0 was my final solution too, because GNU awk(1) didn't
 >  make it by the (presumably more expensive, too) sprintf("%X")
 >  call just as all other tested awk(1)s did.)
 >  
 >  So there is a problem with the implicit type conversion, since
 >  
 >    echo f001 f00d |\
 >    awk '{ a=sprintf("%d", "0x" $1); b=sprintf("%d", "0x" $2); while (a < b) 
 > { print a; a++; }}'
 >  
 >  works just fine?!?

Compare

% echo f001 | awk '{ a="0x" $1; print a, (a > 700); }'  
0xf001 0

% echo f001 | awk '{ a="0x" $1; a=sprintf("%d", a); print a, (a > 700); }'
61441 0

It's not a number; however, the string 61141 is less than the string
61453.

There isn't, as far as I can see, a problem; it's just that while most
of the time this stuff is fully transparent and it always does what
you want, if you start poking at the corners the exact behavior is
sometimes a bit odd.

 >  And because the `Table: Expressions in Decreasing Precedence in awk'
 >  contains the line
 >  
 >    expr < expr   Less than   Numeric   None

What about < on strings?

In particular, if you compare a number and a string, the comparison is
done as a string.

% echo boo | awk '{ a = 1234; a+=0; print (a > "!") }'
1

I was arguing elsewhere recently (PR 47840) that in some cases
pertaining to numeric constants this produces unexpected/unwanted
results and should produce a warning; but in general it's better than
doing such comparisons as numbers.

-- 
David A. Holland
dholland%netbsd.org@localhost