[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220413203835.GW7074@brightrain.aerifal.cx>
Date: Wed, 13 Apr 2022 16:38:35 -0400
From: Rich Felker <dalias@...c.org>
To: "Gary E. Miller" <gem@...lim.com>
Cc: musl@...ts.openwall.com
Subject: Re: *strerror_r() bug in musl
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.
This isn't musl being weird, it's glibc being weird. 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
In general, none of these affect software which is not making
non-portable glibc-specific assumptions.
> Now consider that gpsd supports well over 100 targets, back to POSIX
> 2001. glibc has a long history of changes around strerror_r(), and gpsd
> has to support each one. Then there are all the other libc. That is a
> lot of doc to check. And a lot of #ifdeff version chacks.
>
> 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:
https://wiki.musl-libc.org/faq.html
> 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.
Rich
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.
