summaryrefslogtreecommitdiff
path: root/src/lib/memchr.c
diff options
context:
space:
mode:
authorMartin Roth <martin.roth@se-eng.com>2013-03-11 13:17:27 -0600
committerStefan Reinauer <stefan.reinauer@coreboot.org>2013-04-01 20:52:31 +0200
commitd2be1f11e11b68d88f9065ae75f32d7982cc3fe6 (patch)
treeaa140b6663a227e3c6710b9048cbb1483c49d827 /src/lib/memchr.c
parentd0d7e7d7619e469dc936a579a6ce2adee9425ca6 (diff)
AMD hudson & SB800 - Fix issues with mawk
When calculating the offsets of the various binary blobs within the coreboot.rom file, we noticed that using mawk as the awk tool instead of using gawk led to build issues. This was finally traced to the maximum value of the unsigned long variables within mawk - 0x7fff_ffff. Because we were doing calculations on values up in the 0xffxxxxxx range, these numbers would either be turned into floating point values and printed using scientific notation, or truncated at 0x7fff_ffff. To fix this, we print the values out as floating point, with no decimal digits. This works in gawk, mawk, and original-awk and as the testing below show, seems to be the best way to do this. printf %u 0xFFFFFFFF | awk '{printf("%.0f %u %d", $1 , $1 , $1 )}' mawk: 4294967295 2147483647 2147483647 original-awk: 4294967295 2147483648 4294967295 gawk: 4294967295 4294967295 4294967295 The issue of %d not matching gawk and original-awk has been reported to ubuntu. In the future, I'd recommend that whenever awk is used, a format is specified. It doesn't seem that we can count on the representation being the same between the different versions. Change-Id: I7b6b821c8ab13ad11f72e674ac726a98e8678710 Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/2628 Reviewed-by: Dave Frodin <dave.frodin@se-eng.com> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Diffstat (limited to 'src/lib/memchr.c')
0 files changed, 0 insertions, 0 deletions