Comment 1 for bug 1159933

On Mon, Mar 25, 2013 at 05:59:56PM -0000, Martin Roth wrote:
> Public bug reported:
>
> I'm honestly not sure if this is a bug or just an implementation
> decision, but it's different than gawk or original-awk, so I'm reporting
> it. This caused problems for coreboot which is using awk to calculate
> addresses up at the 0xFFFXXXXX range. We worked around it by using %.0f
> to print the values.
>
> using the test:
> printf %u 0xFFFFFFFF | awk '{printf("%.0f %u %d", $1 , $1 , $1 )}'
>
> mawk:
> 4294967295 2147483647 2147483647
>
> original-awk:
> 4294967295 2147483648 4294967295
>
> gawk:
> 4294967295 4294967295 4294967295

mawk 1.3.4 20130219 is different too, but call it an implementation decision.

+ mawk {printf("%.0f %u %d", $1 , $1 , $1 )}
+ printf %u 0xFFFFFFFF
4294967295 4294967295 2147483647

original-awk and gawk support some form of extended precision, but awk's
use types for data - so the treatment of unsigned values is likely where
you'll see the most (valid) variation. I recall fixing some issue which
is relevant to the handling of unsigned - 1.3.3's equating of the ranges
for %u and %d is arguably a bug.

--
Thomas E. Dickey <email address hidden>
http://invisible-island.net
ftp://invisible-island.net