Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 13 Apr 2022 15:43:14 -0700
From: "Gary E. Miller" <>
Subject: Re: *strerror_r() bug in musl

Yo Rich!

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

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.


Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703  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.