[PATCH v2 03/61] kvargs: add hexadecimal conversion helpers

[fengchengwen]

Acked-by: Chengwen Feng <fengchengwen at huawei.com>

On 9/30/2026 12:36 AM, Stephen Hemminger wrote:
> Several device arguments are documented as a bare hexadecimal mask, with
> no 0x prefix, such as the ice hw_debug_mask, the cxgbe filtermode
> and filtermask, the hns3 dev_caps_mask and the ark Pkt_dir. Each
> open codes strtoull() with base 16, and each gets the validation
> wrong in a familiar way. ice checks errno but not the end pointer,
> cxgbe checks errno without clearing it first, and hns3 checks
> nothing at all, so dev_caps_mask=junk is silently taken as zero.
> 
> The existing helpers cannot be used for these. They read base 16 only
> when the value carries an explicit 0x prefix, so a documented bare mask
> containing a letter, such as "ff", would be rejected outright, while one
> which happens to be all digits, such as "10", would be reread as decimal
> and change from sixteen to ten.
> 
> The second case is the dangerous one: it silently changes the meaning of
> a working command line instead of rejecting it, which is the one kind of
> breakage the rest of this series is careful to avoid.
> 
> Add rte_kvargs_handle_hex32() and rte_kvargs_handle_hex64(), which are
> the same as rte_kvargs_handle_u32() and rte_kvargs_handle_u64() except
> that the value is always read as hexadecimal, whether or not it carries
> a 0x prefix. Expose the underlying rte_kvargs_to_hex() for a mask
> narrower than the target type.
> 
> A sign is rejected, as it is for the unsigned handlers, so a mask cannot
> be given as -1.
> 
> Only the 32 and 64 bit widths are added, since those are the only ones
> any caller needs; the family can be extended on demand.
> 
> Signed-off-by: Stephen Hemminger <stephen at networkplumber.org>