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

[Paul Eggert]

On 2024-07-25 14:27, Bruno Haible wrote:

> I have a hard time understanding the point
> and purpose of what you are saying:
>    - In <https://lists.gnu.org/archive/html/bug-gnulib/2024-07/msg00171.html>
>      you removed the validation of 'base', saying:
>        "strtol can support base 1 as an extension, xstrtol now does
>         whatever the system does".
>    - In <https://lists.gnu.org/archive/html/bug-gnulib/2024-07/msg00238.html>
>      you agreed to leaving it unspecified whether xstrtol sets *endptr
>      in some case.

Fair enough, I suppose I added too much gingerbread there, so I 
installed the attached patch to go back to the old way of doing things, 
as that is simpler, less confusing, and a bit more efficient. The idea 
is to not worry about hypothetical implementations or applications, just 
real ones. The only thing missing from the old way of doing things, was 
documentation that you shouldn't call xstrtol with a base other than 0 
or 2 through 36, so the attached patch adds this to xstrtol.h.


> documentation like "If you pass a base other than 0 or 2..36, you
> can't expect a particular parsing, nor a particular error code, nor a
> particular value for *endptr." is good.

I'm afraid we'll have to disagree on this particular case. It's OK for 
behavior to be undefined when the base is bad, just as it's OK for it to 
be undefined if the string is bad (e.g., when nptr == (char *) &errno). 
There's no real-world hazard, and this email thread has taken more of 
our time than the issue is worth.

I didn't adjust the recently-added Gnulib test cases even though they're 
testing what is now documented to be undefined behavior, as they still 
pass on the FreeBSD and Ubuntu platforms that I tried them on. If they 
start failing we can remove them as needed. They're not testing anything 
important, after all.

0001-xstrtol-remove-the-base-checking-changes.patch
Description: Text Data