Subject: Re: bug#73068: printf: please implement POSIX:2024 argument reordering

From: Pádraig Brady <[email-masked]>
Date: Fri, 13 Sep 2024 17:32:41 +0100

On 13/09/2024 13:55, Pádraig Brady wrote:
> On 12/09/2024 20:33, Paul Eggert wrote:
>> On 2024-09-12 12:03, Pádraig Brady wrote:
>>
>>
>>> This is tricky enough, that we should be as restrictive as possible here,
>>> so I may resort to strspn(f, "0123456789") to parse instead.
>>> I'll think a bit about it.
>>
>> The code's also assuming INT_MAX < INTMAX_MAX, which POSIX doesn't
>> require. You could put in a static_assert to that effect, I suppose, to
>> document the assumption.
> 
> Indeed. We would have incorrectly taken the INTMAX_MAX arg in the
> (albeit unlikely) case where INT_MAX >= INTMAX_MAX,
> and the provided number overflowed INTMAX_MAX.
> To be explicit, strtol() doesn't return 0 in that case,
> so we need to check overflow (like Colin suggested).
> 
>> More important, though, if you're not in the C locale all bets are off
>> as far as what strtoimax will also parse.
>>
>> When I ran into this problem with GNU tar, I ended by giving up on
>> strtoimax and did my own little integer parser. It does exactly what I
>> want and I don't have to fire up the strtoimax complexity+locale engine.
> 
> Right, it's best to preparse for the above reason,
> and to avoid any confusion re leading spaces etc. like I previously mentioned.
> 
> The attached adjustment does the preparse with strspn(),
> and only does the strtoimax() for appropriate strings.

I adjusted and pushed a further simplification that
clamps %<huge values>$ to %INT_MAX$, which is equivalent
as argc can practically only be <= INT_MAX - 2.
That simplifies the strtoimax() error handling,
and removes any limits on valid decimal numbers.

cheers,
Pádraig