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. :) > > - 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/>
signature.asc
Description: PGP signature
