]> git.baikalelectronics.ru Git - uboot.git/commit
Revert "lib: Improve _parse_integer_fixup_radix base 16 detection"
authorSean Anderson <seanga2@gmail.com>
Sun, 7 Jun 2020 05:36:45 +0000 (01:36 -0400)
committerTom Rini <trini@konsulko.com>
Mon, 15 Jun 2020 15:23:41 +0000 (11:23 -0400)
commitf0dbec940d027de8c233becee40dea58d9893643
treeb460871510ae3001083ec65413338416e085422a
parent6d13524e032e09ce514ea42107f709d8000c70bf
Revert "lib: Improve _parse_integer_fixup_radix base 16 detection"

This reverts commit 161bc46ea378e96f5c4bcb7a76fff61aedc5296a.

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>
lib/strto.c