Re: [musl] *strerror_r() bug in musl

["Gary E. Miller" <gem@rellim.com>]

[-- Attachment #1: Type: text/plain, Size: 3408 bytes --]

Yo Rich!

On Wed, 13 Apr 2022 18:27:58 -0400
Rich Felker <dalias@libc.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@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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 851 bytes --]