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

[Rich Felker <dalias@libc.org>]

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@libc.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