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.