Yo Rich! On Wed, 13 Apr 2022 18:58:43 -0400 Rich Felker wrote: > On Wed, Apr 13, 2022 at 03:43:14PM -0700, Gary E. Miller wrote: > > > > 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? > > It's not part of our documentation because it has nothing to do with > musl. As far as I can tell, you're only perceiving it as being > "something about musl" because glibc is the frame of reference you're > used to. Uh, I was not the one that brought up __GLIBC__. I always considered it out of scope here in musl-land. > > > - Using standard macros provided by the implementation that > > > describe interfaces available: good. > > > > Except, musl does not provide any? Or did I miss something? > > The macros from unistd.h declare conformance to the standards and > which option groups are provided. I just compared musl unistd.h to glibc unistd.h. glibc has many more standards handled than just POSIX. But don't fix that on my account, I'm just saying... > There is a proposal for extending this system with information about > extensions that aren't standardized, that was discussed on the > libc-coord mailing list, but it never really moved forward. Then we are now on the same page here. "unimplemented" but might be nice. 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