[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
