From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=DKIM_ADSP_ALL, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28496 invoked from network); 13 Apr 2022 21:17:14 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 13 Apr 2022 21:17:14 -0000 Received: (qmail 32580 invoked by uid 550); 13 Apr 2022 21:17:11 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 32548 invoked from network); 13 Apr 2022 21:17:10 -0000 Date: Wed, 13 Apr 2022 14:16:52 -0700 From: "Gary E. Miller" To: musl@lists.openwall.com Message-ID: <20220413141407.27cec2a1@spidey.rellim.com> In-Reply-To: <20220413203835.GW7074@brightrain.aerifal.cx> References: <20220412134355.59bd920e@spidey.rellim.com> <20220413142432.311e20f5@ncopa-desktop.lan> <20220413140532.GT7074@brightrain.aerifal.cx> <20220413103651.0087ca81@spidey.rellim.com> <20220413203835.GW7074@brightrain.aerifal.cx> Organization: Rellim X-Mailer: Claws Mail 4.1.0 (GTK 3.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/oyTUPQ5Vb3h_XuSQHH2lJo/"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Re: [musl] *strerror_r() bug in musl --Sig_/oyTUPQ5Vb3h_XuSQHH2lJo/ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Yo Rich! On Wed, 13 Apr 2022 16:38:35 -0400 Rich Felker wrote: > On Wed, Apr 13, 2022 at 10:36:51AM -0700, Gary E. Miller wrote: > > Yo Rich! > >=20 > > On Wed, 13 Apr 2022 10:05:33 -0400 > > Rich Felker wrote: > > =20 > > > > > When _GNU_SOURCE is defined with glibc, then strerror_r() > > > > > returns a char *. =20 > > > >=20 > > > > I have met this in multiple places the last decade. The usual > > > > way to fix it is to also check for GNU libc in addition to > > > > _GNU_SOURCE. > > > >=20 > > > > #if defined (__GLIBC__) && defined (_GNU_SOURCE) > > > > /* non-standard GLIBC exception */ > > > > #else > > > > /* standard behavior for everything else */ > > > > #endif =20 > > >=20 > > > That, or probe for the signature with a configure-style check and > > > use the result of that, as in > > >=20 > > > #ifdef HAVE_GNU_STRERROR_R > > > // handle the GNU version > > > #else > > > // code written to the standard > > > #endif =20 > >=20 > > gpsd runs on a huge variety of hardware and software. We used to > > have rats nests of #ifdef's as suggested above. But that only > > works when your library code actually follows your documentation, > > and our dev actually read and understood your documentation. > >=20 > > Since you doc fails to mention this "quirk", it is not possible to > > forsee this issue before debugging the rare crash. =20 >=20 > Our docs say we aim to conform to ISO C and POSIX. The alternate glibc > strerror_r does not conform to POSIX and therefore we don't do it. The musl docs also say you conform to FNU_SOURCE. Two incompatible statements. > This isn't musl being weird, it's glibc being weird. Agreed. musl is insufficiently documented, and glibc is seird. Although to be fair, they invented strerror_r() first, and POSIX munged the copy. > I agree it would > be helpful to highlight this difference though. We have material on > the wiki covering a bunch of differences from glibc, but somehow this > was overlooked: > https://wiki.musl-libc.org/functional-differences-from-glibc.html Since it fails to mention strerror() or strerror_r(), it will never how up as a result of an internet search. Easy to fix. For you, not me. May I suggest a more obvious place as well: https://musl.libc.org/doc/1.1.24/manual.html It currently says: _GNU_SOURCE (or _ALL_SOURCE) Adds everything above, plus interfaces modeled after GNU libc extensions and interfaces for making use of Linux-specific features. Change that to add: Except wher the GNU extensions conflict with POSIX. And link to the wiki on glibc > In general, none of these affect software which is not making > non-portable glibc-specific assumptions. Afer reading your doc, I thought that was the case for gpsd. The two fixes above should be a big improvement. > > OBTW: did I mention musl does not appear to have any #defines to > > specify its current version? Or even that it is musl? Or did I > > miss something else in the doc? =20 >=20 > No, that's intentional. The macros that tell you what to expect are > _POSIX_VERSION and others from unistd.h. Attempting to hard-code > asssumptions about musl is explicitly unsupported usage. You have to > either detect or just assume standard behavior. It's covered in the > FAQ: And yet, I'm supposed to check the GNU feature macros? So their defines are good? But musl not having the equivalent is good? Get your story straight please. But, as I have said before, gpsd does prefer not to use feature #defines either. Because they are a mess. One that includes musl. > > So you expect me to use the glibc #defines, because musl lacks > > them. =20 >=20 > No, I expect you not to assume non-conforming glibc behavior on > platforms that aren't glibc. The same would apply on any of the BSDs. No assumptions were made, except that your doc meant what it appeared to say. We all agree that it does not mean what it appears to say. Easy to fix, I leave it to you folks to do so. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin --Sig_/oyTUPQ5Vb3h_XuSQHH2lJo/ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAEBCgAdFiEEDImNR/2vUKZZKLG0LmvF3i7oaj4FAmJXPcQACgkQLmvF3i7o aj4uPA//fKuXYoea+C55tM/Y9E8slMh3hEeD7ONgBf6BLwRL8VXJ99i6J6z7yTQ1 EwX17INLe8PyCXVUjZ19G5c2nzrF5Qu18d7rbYqgA/nhJ4atjzTTN3PjlMbP+ZAV oZiYLbz0LdlOdb+A2iIh4CXapSnjAmWTyZztBEgiV5Z+uKde1uN06ykKJFPA2dAo euA/63JrhXsw/U0Cxx42j32t1y+zDplVwfzN5pFZmbP+TLp+SeqWlgDJdl+CP+iw PdjdSi2GcENf1iOV9349t9bSFvstW46A1Qj5LhW521LDPEE5xiIchmmQx0do1pif WUFyXzj+9ShB/SyWJ4GHbVQE0j9J4Ys4TIZKDVW++UFd2K/bbhQ4Cs5TFneU80wL O+fGAqAbJwQE8ziFPa91aZ7GZ01ziDn6paSlbPl4zSvhLe8yAyNMdipe2Z3YWTnq O9YCAjSq/bCS7aK4cQnw4gpC2v5Sty2IhYHjDwmTdgYHhxVLkbeoMIUs2Lu3ZHnI oe3mXLPTT1t2y7irQpN5rH80xD1ooPQCwtLRVoKtvvIdFRnbi+eavoKH2FpDajFC lSq5LrjsqwVOqr3PTcLAvzdK9N35lcdvAsEXF4MB90VmQvPykFYp1NLAy2O3GSvG 3CaxK9GPCkzEFJOZrCVjvV8ZHCjbi/e71BhlO6QT8Xs3lx6InHA= =QY4C -----END PGP SIGNATURE----- --Sig_/oyTUPQ5Vb3h_XuSQHH2lJo/--