Re: [PATCH v12 1/3] cmdline: use C standard library as number parser

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

On 2/26/2026 6:23 PM, Bruce Richardson wrote:
> On Thu, Feb 26, 2026 at 04:44:48PM +0000, Anatoly Burakov wrote:
>> Remove custom number parser and use C standard library instead. In order to
>> keep compatibility with earlier versions of the parser, we have to take
>> into account a couple of quirks:
>>
>> - We did not consider "negative" numbers to be valid for anything other
>>    than base-10 numbers, whereas C standard library does. Adjust the tests
>>    to match the new behavior.
>> - We did not consider numbers such as "+4" to be valid, whereas C
>>    standard library does. Adjust the tests to match the new behavior.
>> - C standard library's strtoull does not do range checks on negative
>>    numbers, so we have to parse knowingly-negative numbers as signed.
>> - Some C standard library versions do not support binary numbers, so we
>>    keep around the relevant parts of the custom parser in place to support
>>    them. However, since those libc versions that do support them also
>>    support them being negative, allow negative binary in our parser as well.
>>
>> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
>> ---
>>
>> Notes:
>>      v10 -> v11:
>>      - Fixed all checkpatch warnings
>>      
>>      v9 -> v10:
>>      - Fixed commit message not reflecting changes for v9
>>      - Reworked enum range check to avoid compile issues on some platforms
>>      
>>      v8 -> v9:
>>      - glibc 2.38 supports binary formats (0bxxxx and -0bxxxx) under certain conditions,
>>        so in order to ensure the same functionality on all glic versions, add support for
>>        positive and negative binary formats, and adjust tests accordingly
>>      
>>      v7 -> v8:
>>      - Added the commented-out out-of-bounds check back
>>      - Replaced debug print messages to ensure they don't attempt to
>>        index the num_help[] array (should fix compile errors)
>>      
>>      v5 -> v6:
>>      - Allowed more negative numbers (such as negative octals or hex)
>>      - Updated unit tests to check new cases
>>      - Small refactoring of code to reduce amount of noise
>>      - More verbose debug output
>>      
>>      v4 -> v5:
>>      - Added this commit
>>
>>   app/test/test_cmdline_num.c     |  34 ++-
>>   lib/cmdline/cmdline_parse_num.c | 421 ++++++++++++++++----------------
>>   2 files changed, 248 insertions(+), 207 deletions(-)
>>
> 
> While I realise there is some additional test content here, I'm surprised
> that replacing a custom number parser with the standard one doesn't
> actually result in any code saving. The code is as long as before!

We could've, if we didn't have to support binary numbers - most of the 
parser is left intact because not all libc versions support binary 
numbers. I mean, glibc 2.38 was released in 2023 so it's not even safe 
to assume every LTS distribution is on it, but more importantly other 
libc implementations (e.g. musl) don't support binary numbers, which is 
why we still need the binary parser.

> 
> However, code size is no reason not to accept this, so:
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> 


-- 
Thanks,
Anatoly