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
