mawk %d maxes out at 0x7FFFFFFF instead of 0xFFFFFFFF
Bug #1159933 reported by
Martin Roth
This bug affects 4 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
mawk (Debian) |
Fix Released
|
Unknown
|
|||
mawk (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
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
I'm using ubuntu 12.04.02 LTS, and mawk 1.3.3-17.
Changed in mawk (Debian): | |
status: | Unknown → New |
Changed in mawk (Debian): | |
status: | New → Confirmed |
Changed in mawk (Debian): | |
status: | Confirmed → Fix Released |
To post a comment you must log in.
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.
-- invisible- island. net -island. net
Thomas E. Dickey <email address hidden>
http://
ftp://invisible