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

[Alejandro Colomar <alx%kernel.org@localhost>]

The following reply was made to PR lib/58461; it has been noted by GNATS.

From: Alejandro Colomar <alx%kernel.org@localhost>
To: Robert Elz <kre%munnari.oz.au@localhost>
Cc: gnats-bugs%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, 
	Paul Eggert <eggert%cs.ucla.edu@localhost>
Subject: Re: lib/58461: strtoi(3) is not portable
Date: Wed, 24 Jul 2024 13:16:39 +0200

 --6rzij5xhpgtwpxns
 Content-Type: text/plain; protected-headers=v1; charset=utf-8
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 From: Alejandro Colomar <alx%kernel.org@localhost>
 To: Robert Elz <kre%munnari.oz.au@localhost>
 Cc: gnats-bugs%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, 
 	Paul Eggert <eggert%cs.ucla.edu@localhost>
 Subject: Re: lib/58461: strtoi(3) is not portable
 References: <lrsaw6f7bzrygmzcjmtmzi6esbw3gwvkkcfzh7gc5777hvxupm@watpgasqovu6>
  <pr-lib-58461%gnats.netbsd.org@localhost>
  <20240723231504.6A0FA1A923C%mollari.NetBSD.org@localhost>
  <20240724014002.1EB2A1A923B%mollari.NetBSD.org@localhost>
  <19925.1721815029%jacaranda.noi.kre.to@localhost>
 MIME-Version: 1.0
 In-Reply-To: <19925.1721815029%jacaranda.noi.kre.to@localhost>
 
 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@watp=
 gasqovu6>
 >=20
 >   | 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,
 >=20
 > 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.  :(
 >=20
 > 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,
 >=20
 > 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.
 
 >=20
 >=20
 >   | If you do, please add
 >   | 	Reported-by: Alejandro Colomar <alx%kernel.org@localhost>
 >=20
 > 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 mark=
 s)
 >   | strtoi(3) would need to be patched because it hardcoded the bases.  B=
 ut
 >   | it is how it is, it seems.
 >=20
 > 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.
 >=20
 > kre
 >=20
 > 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
 
 --=20
 <https://www.alejandro-colomar.es/>
 
 --6rzij5xhpgtwpxns
 Content-Type: application/pgp-signature; name="signature.asc"
 
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmag4pEACgkQnowa+77/
 2zL5Yg/+PiIEV0HoYE7TM2oTOnym3r69ul43TLacHGBRwnO2K7WrpUTtc8Oae2H/
 LHzsBbxCcJJ0KGHFEASQKA2Ulqs2D2gzx10twMit6WScQzp2G6qHdEd+0VhWmGlg
 CE+w2zmRHLDTFsqSGkv8rfNlMTRyBdTt0WyWjHtlizQxSMUGdctzLnKBHo1q4pVA
 P2iyW97AP41+Ou43BtDeA91Ymi3ce5e5DKp4Ptku3pf888EON6Ln+W9GW29VbhbD
 oC7jvwiteTFFg4qYpWCIJ2hU9/1G4kP22kgFRZndhLKAL/x314/niMLrxJjhxWs2
 2B3V20h0Fr6hqKe/iwbs2OSjyKhLyKkyBLR9MmGx5ZmgfJMT1g9llPGI1NY+Tobt
 OP1VFpKpObq1YHuBXKL+uTVlA6ppLItqVMjjGEyHpoaB2iIXtYKdHBtzsoe9UdqI
 msTxJYe6lc8DdJRul0XlnZiMQiZhjJTbuZzjlgqKQsXGJa1112vYbad9uRu2/RhA
 qvvstZhrZWe4VYa1p0CiyT84EHYVhc5oG3TaFr26KUW/6c3QnZ4WUo7XqZqApQGh
 EWnJTeljrxsybBCgdm/LJ5wTcdttmv1LyBnmibDZgArPOxmUMuq+Ef1hJwn0fJgV
 ZHHn31VwxvoPTyW5tV48VJ6qmHZyK7frYt66p5nLN0xILix+GaU=
 =gjQ1
 -----END PGP SIGNATURE-----
 
 --6rzij5xhpgtwpxns--