[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 13 Apr 2022 14:16:52 -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 16:38:35 -0400
Rich Felker <dalias@...c.org> wrote:
> On Wed, Apr 13, 2022 at 10:36:51AM -0700, Gary E. Miller wrote:
> > Yo Rich!
> >
> > On Wed, 13 Apr 2022 10:05:33 -0400
> > Rich Felker <dalias@...c.org> wrote:
> >
> > > > > When _GNU_SOURCE is defined with glibc, then strerror_r()
> > > > > returns a char *.
> > > >
> > > > I have met this in multiple places the last decade. The usual
> > > > way to fix it is to also check for GNU libc in addition to
> > > > _GNU_SOURCE.
> > > >
> > > > #if defined (__GLIBC__) && defined (_GNU_SOURCE)
> > > > /* non-standard GLIBC exception */
> > > > #else
> > > > /* standard behavior for everything else */
> > > > #endif
> > >
> > > That, or probe for the signature with a configure-style check and
> > > use the result of that, as in
> > >
> > > #ifdef HAVE_GNU_STRERROR_R
> > > // handle the GNU version
> > > #else
> > > // code written to the standard
> > > #endif
> >
> > gpsd runs on a huge variety of hardware and software. We used to
> > have rats nests of #ifdef's as suggested above. But that only
> > works when your library code actually follows your documentation,
> > and our dev actually read and understood your documentation.
> >
> > Since you doc fails to mention this "quirk", it is not possible to
> > forsee this issue before debugging the rare crash.
>
> Our docs say we aim to conform to ISO C and POSIX. The alternate glibc
> strerror_r does not conform to POSIX and therefore we don't do it.
The musl docs also say you conform to FNU_SOURCE.
Two incompatible statements.
> This isn't musl being weird, it's glibc being weird.
Agreed. musl is insufficiently documented, and glibc is seird. Although
to be fair, they invented strerror_r() first, and POSIX munged the copy.
> I agree it would
> be helpful to highlight this difference though. We have material on
> the wiki covering a bunch of differences from glibc, but somehow this
> was overlooked:
> https://wiki.musl-libc.org/functional-differences-from-glibc.html
Since it fails to mention strerror() or strerror_r(), it will never how
up as a result of an internet search. Easy to fix. For you, not me.
May I suggest a more obvious place as well:
https://musl.libc.org/doc/1.1.24/manual.html
It currently says:
_GNU_SOURCE (or _ALL_SOURCE)
Adds everything above, plus interfaces modeled after GNU libc
extensions and interfaces for making use of Linux-specific features.
Change that to add:
Except wher the GNU extensions conflict with POSIX.
And link to the wiki on glibc
> In general, none of these affect software which is not making
> non-portable glibc-specific assumptions.
Afer reading your doc, I thought that was the case for gpsd.
The two fixes above should be a big improvement.
> > OBTW: did I mention musl does not appear to have any #defines to
> > specify its current version? Or even that it is musl? Or did I
> > miss something else in the doc?
>
> No, that's intentional. The macros that tell you what to expect are
> _POSIX_VERSION and others from unistd.h. Attempting to hard-code
> asssumptions about musl is explicitly unsupported usage. You have to
> either detect or just assume standard behavior. It's covered in the
> FAQ:
And yet, I'm supposed to check the GNU feature macros? So their defines
are good? But musl not having the equivalent is good?
Get your story straight please.
But, as I have said before, gpsd does prefer not to use feature #defines
either. Because they are a mess. One that includes musl.
> > So you expect me to use the glibc #defines, because musl lacks
> > them.
>
> No, I expect you not to assume non-conforming glibc behavior on
> platforms that aren't glibc. The same would apply on any of the BSDs.
No assumptions were made, except that your doc meant what it appeared to
say. We all agree that it does not mean what it appears to say.
Easy to fix, I leave it to you folks to do so.
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.
