Re: [PATCH] lib/xstrtol.c: Fix xstrtol() on EINVAL (invalid base)

[Alejandro Colomar]

On Wed, Jul 24, 2024 at 10:54:52PM GMT, Alejandro Colomar wrote:
> Hi Paul,
> 
> On Wed, Jul 24, 2024 at 01:11:33PM GMT, Paul Eggert wrote:
> > On 2024-07-24 12:27, Alejandro Colomar wrote:
> > > POSIX leaves the value of *endptr unspecified if the base is invalid;
> > > it is not unmodified.
> > 
> > Fine, we can let xstrtol do the same.
> > 
> > > That, combined with the fact that POSIX allows implementations of
> > > strtol(3) to set EINVAL when no digits are found, makes it impossible to
> > > portably check if the base was valid after the call.
> > 
> > I don't see why not. Current gnulib xstrtol.c does something reasonable if
> > the base is invalid. Why isn't that good enough?
> 
> The following is a POSIX-compliant implementation of strtol(3):
> 
> On an invalid base:
> 
>    -  *endptr = nptr  // POSIX leaves it unspecified so this is valid
>    -  errno = EINVAL  // POSIX mandates this
>    -  return 0                // POSIX mandates this
> 
> On no digits:
> 
>    -  *endptr = nptr  // POSIX mandates this
>    -  errno = EINVAL  // POSIX explicitly allows this
>    -  return 0                // POSIX mandates this
> 
> Find the 7^W 0 differences.  :)

I forgot to reply to the last part: "Why isn't that [current gnulib]
good enough?

With an implementation of strtol(3) that does what I wrote above, the
test `if (!t_ptr)` isn't true, so we go to
`if (*p == nptr && (errno == 0 || errno == EINVAL))`, which is true.

Assuming that the string matches a valid suffix, it'd succeed, but the
call should have failed early.  (And the worst part might be suggesting
readers that an invalid base can be successfully tested after a call to
strtol(3), so that they do something similar.)

> 
> > > -  char *t_ptr = nullptr;
> > > +  char *t_ptr;
> > >     char **p = endptr ? endptr : &t_ptr;
> > > +  *p = (char *) nptr;
> > > +
> > > +  if (base < 0 || base == 1 || 36 < base)
> > > +    return LONGINT_INVALID;
> > > +
> > 
> > This would cause xstrtol to fail even if the underlying strtol supports base
> > 1, base 64, etc. Why would we want to do that?
> 
> We don't want to do that.  But we have no choice.  :-)
> 
> > > I'm tired of strtol(3).  :)
> > 
> > Likewise. This issue about an invalid base is unimportant in practice, as
> > the base is almost invariably a valid constant.
> 
> Have a lovely night!
> Alex
> 
> -- 
> <https://www.alejandro-colomar.es/>



-- 
<https://www.alejandro-colomar.es/>

signature.asc
Description: PGP signature