Hi Robert, On Wed, Jul 24, 2024 at 04:57:09PM GMT, Robert Elz wrote: > Date: Wed, 24 Jul 2024 11:17:30 +0200 > From: Alejandro Colomar <alx%kernel.org@localhost> > Message-ID: <lrsaw6f7bzrygmzcjmtmzi6esbw3gwvkkcfzh7gc5777hvxupm@watpgasqovu6> > > | I documented in the Linux man-pages that it is impossible to portably > | detect an invalid base _after_ a call to strtol(3), as you say. And > | thus it only makes sense to validate the base before the call, which > | makes the POSIX decision to report EINVAL completely bogus, > > No, the EINVAL on an invalid base is fine. The problem is the EINVAL > when there are no digits. That's unnecessary, that situation can be > detected other ways, an errno value for it is not needed. Ah, yeah; I was assuming we can't change the fact that some systems do EINVAL on no digits. That is indeed the first sin. [...] > | I see that FreeBSD, OpenBSD, and Bionic libc (Android) also set nptr on > | an invalid base. It seems glibc and musl are the weirdos here. :( > > That difference isn't what matters. It is the other use of EINVAL > that breaks things. Agree. > | Robert, would you mind opening a bug report for POSIX, > > I could, I'll see what might work - there's little point in reporting > things that would just be rejected. This gets messier as the exact > same text is in all of the (fleshed out) function specifications (I > mean, unlike strtoumax() which just appears in the strtoimax() page). The change can (and should) be applied to all such pages. > > > | If you do, please add > | Reported-by: Alejandro Colomar <alx%kernel.org@localhost> > > I can do that, if I find some wording that would be reasonable. > Do remember that POSIX is definitely not intended to be a tutorial, > its readers are expected to know what it means when something is > left unspecified or undefined, particularly when the APPLICATION USAGE > already points out the issue. I think the latter (shorter) wording might be better. It only removes part of the already existing tutorial; it's not adding any tutorial. And the current tutorial is wrong, since it won't work on some POSIX- compliant systems. > | Yeah, that was my original approach, which has the downside that if a > | system adds support for other bases (e.g., base 1, a.k.a., tally marks) > | strtoi(3) would need to be patched because it hardcoded the bases. But > | it is how it is, it seems. > > Yes, that is the problem. We could fix that (at least for strtoi()) > by simply making the base verification code a function, and calling that > from everywhere else (and since the test it would do is so simple, it > could even be an inline function), but other applications (outside callers > inside libc) couldn't get the benefit of that. > > kre > > ps: submitting POSIX defect reports isn't all that difficult, though it > is tedious, as their bug system (MANTIS) is not good - almost as bad as > gnats! Actually, I didn't have any problems with gnats. Maybe that it doesn't provide a link to the report in the mail, and that I can't easily add someone to CC, and also that it's hard to see in the website where a message ends and the next one starts, and the aqueducts and the wine, but other than that it's not too bad. :) > But you do need an opengroup login to be able to submit things. That's where I haven't been able to arrive yet, I think. Getting one of those is a nightmare, or I was very stupid back when I tried. I got an account for something, but that account didn't give me access to other things and I seemed to have to create another account for somethign else. I don't remember the details, but remember that it was too bad. Have a lovely day! Alex -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature