Re: lib/58461: strtoi(3) is not portable

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    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.

If EINVAL only ever meant that base was invalid (or perhaps some other
invalid args - though I don't believe there are any), then there would
be no issue, all that would be necessary is to check for (errno == EINVAL)
before doing anything else after a call to strtoimax() (or strtowhatever()).

But it doesn't.   And there's nothing much we can do about that.

  | And so ISO C's choice of leaving the behavior undefined
  | on an invalid base was actually better

Not really, nothing would really alter if it were like that.

  | (POSIX probably only codified implementations's behavior;

Yes, that happens all the time, unless someone happens to realise
that some implementations are simply broken, and should not be
permitted.   That generally needs to happen when an interface is
first added however, except in the very rare case that implementations
later converge on sane behaviour, and the allowed difference is no
longer needed by anyone, and can be deleted.

  | 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.

  | 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).


  | 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.

  | 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!   But you do need an opengroup login to be able to submit things.