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 6988 invoked from network); 13 Apr 2022 22:43:30 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 13 Apr 2022 22:43:30 -0000 Received: (qmail 12131 invoked by uid 550); 13 Apr 2022 22:43:27 -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 12098 invoked from network); 13 Apr 2022 22:43:27 -0000 Date: Wed, 13 Apr 2022 15:43:14 -0700 From: "Gary E. Miller" To: musl@lists.openwall.com Message-ID: <20220413154314.006b6622@spidey.rellim.com> In-Reply-To: <20220413222758.GX7074@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> <20220413141407.27cec2a1@spidey.rellim.com> <20220413222758.GX7074@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_/4EszsM9_Fw_QvHCoRLfHDuo"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Re: [musl] *strerror_r() bug in musl --Sig_/4EszsM9_Fw_QvHCoRLfHDuo Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Yo Rich! On Wed, 13 Apr 2022 18:27:58 -0400 Rich Felker wrote: > > The musl docs also say you conform to FNU_SOURCE. =20 >=20 > No it does not, and I'm not even sure what "conform to" would mean > here. The Conformance section in the Introduction covers what musl > attempts to conform to, The Library Interfaces section (where the > current manual ends) reiterates that: >=20 > "For all interfaces provided by musl that are specified by standards > to which musl aims for conformance, the relevant standards documents > are the official documentation." >=20 > The manual does say that _GNU_SOURCE exposes additional extension > interfaces. Not that it works like in glibc and changes the behavior > of standard interfaces. You read that into it. I agree reading that > into it is an easy misreading and that's why I want to make it more > clear. Can we agree it is very misleading and needs to be improved? > > Change that to add: > >=20 > > Except wher the GNU extensions conflict with POSIX. =20 >=20 > Something like that. I would say that we should just be explicit that > this is about exposing additional interfaces only and does not change > the behavior of any standard interface. It's not an exception to > what's written before it. The statement before it is already accurate. Accurate, but misleading to the casual observer. > So, at the end of the bulleted list, something like: >=20 > "As interpreted by musl, feature test macros only control what > interfaces are exposed. They do not alter the behavior of any function > or change the definition of any type. In particular, `_GNU_SOURCE` > does not cause the signatures or behaviors of functions to change > where GNU libc deviated from the requirements of the standards." Works for me. Thank you. > > And yet, I'm supposed to check the GNU feature macros? So their > > defines are good? But musl not having the equivalent is good? =20 >=20 > If you're using __GLIBC__ to work around an intentional glibc > nonconformance issue, that's reasonable usage of it and part of the > way they intend for you to be able to use it. So you intend for me to use __GLIBC__, for something I'm not sure about, when __GLIBC__ is not part of your package or defined in your doc? I'll stick to direct configure tests. > > Get your story straight please. =20 >=20 > I don't see where it's inconsistent. >=20 > - Using standard macros provided by the implementation that describe > interfaces available: good. Except, musl does not provide any? Or did I miss something? On second thought, don't bother, I'll stick to direct configure tests. > - Providing macros that identify an implementation by name and version > and expecting applications to hard-code knowledge about that > implementation: bad. I look forward to your glibc bug report on their implementing that badness. Let's bet on how long before they take that advice? I'll stick to direct configure tests. > - Doing the best you can do with what glibc gave you: okay. Always. 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_/4EszsM9_Fw_QvHCoRLfHDuo Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAEBCgAdFiEEDImNR/2vUKZZKLG0LmvF3i7oaj4FAmJXUgIACgkQLmvF3i7o aj40xhAAgzNnOoV3DHA96V+P5x+MFxvjVJ8sdf0joz2ieczcVqGRGB1/jnprI4UZ 9uae61Q1No47lmwpVV2vwk08psbJOxR341HIqSraof+OKjnompvFHpGWrCJ/vxj4 qowLdgIksqazlaEeiwgvwb1W+35Be1ZZtOe6oi5QjI2B/DIlMG+WzgSDvRueohrc Qf4L1LdPLlCg6+//Yap6cxlDFYeb92erw7YFC1jA43MCdDguLYVEijn4Se9JcSJS E6nospXFsTn9ngTBVsOSZ37e6qtuG3/RjJ2hOWzGFaMB/SO1BQFHNu17OUaxy0y2 LGv7OZd7nh3t2vbixzM2vrrqIft9uMS1tfnVENDPpDW3BWZykYSbfxijHp91ITjg zuivMKWfwKpt5gY+tE7PYTZKiXbpOllWHk1Kr/h6qODZzK9FiyWgrxYAWdw0SD1s G1HND6zpmE5jq/yjbQrkXpOwBNjrzM5eB3AXEf4h816rk69uLqlbHYS+LTaC94tY g1ID4d6SwXDEdvpI8i5zKZbsgqP+R6Ibi+LEf4PVlqeItdjY73hCqPsFJiwtNKcw TrSogthvDAr/7M+fncdlKMcHeuvxuJiSVnCD2ucl0Eiu83M0NVEFkaIRHOdslKjW LO8hvTCkFG7TyVQ9m55zJMiehma+12gMDQh3C+6wl0uG1UJnzHs= =hMHb -----END PGP SIGNATURE----- --Sig_/4EszsM9_Fw_QvHCoRLfHDuo--