summaryrefslogtreecommitdiff
path: root/Kconfig
diff options
context:
space:
mode:
authorSean Anderson <seanga2@gmail.com>2020-06-07 08:36:45 +0300
committerTom Rini <trini@konsulko.com>2020-06-15 18:23:41 +0300
commit1fae74125b644bb7f21e4afef3b9084c58e7863a (patch)
treeb460871510ae3001083ec65413338416e085422a /Kconfig
parenta633a804a2a32693180ef156ed1a2dbc70b6d392 (diff)
downloadu-boot-1fae74125b644bb7f21e4afef3b9084c58e7863a.tar.xz
Revert "lib: Improve _parse_integer_fixup_radix base 16 detection"
This reverts commit 0486497e2b5f4d36fa968a1a60fea358cbf70b65. The strtoul has well-defined semantics. It is defined by the C standard and POSIX. To quote the relevant section of the man pages, > If base is zero or 16, the string may then include a "0x" prefix, and the > number will be read in base 16; otherwise, a zero base is taken as 10 > (decimal) unless the next character is '0', in which case it is taken as > 8 (octal). Keeping these semantics is important for several reasons. First, it is very surprising for standard library functions to behave differently than usual. Every other implementation of strtoul has different semantics than the implementation in U-Boot at the moment. Second, it can result in very surprising results from small changes. For example, changing the string "1f" to "20" causes the parsed value to *decrease*. Forcing use of the "0x" prefix to specify hexidecimal numbers is a feature, not a bug. Lastly, this is slightly less performant, since the entire number is parsed twice. This fixes the str_simple_strtoul test failing with test/str_ut.c:29, run_strtoul(): expect_val == val: Expected 0x44b (1099), got 0x1099ab (1087915) test/str_ut.c:46, str_simple_strtoul(): 0 == run_strtoul(uts, str2, 0, 1099, 4): Expected 0x0 (0), got 0x1 (1) Signed-off-by: Sean Anderson <seanga2@gmail.com> CC: Michal Simek <michal.simek@xilinx.com> CC: Shiril Tichkule <shirilt@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Diffstat (limited to 'Kconfig')
0 files changed, 0 insertions, 0 deletions