Date: Wed, 13 Apr 2022 15:43:14 -0700 From: "Gary E. Miller" <gem@...lim.com> To: musl@...ts.openwall.com Subject: Re: *strerror_r() bug in musl Yo Rich! On Wed, 13 Apr 2022 18:27:58 -0400 Rich Felker <dalias@...c.org> wrote: > > The musl docs also say you conform to FNU_SOURCE. > > 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: > > "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." > > 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: > > > > Except wher the GNU extensions conflict with POSIX. > > 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: > > "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? > > 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. > > I don't see where it's inconsistent. > > - 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@...lim.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 Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.