Date: Wed, 13 Apr 2022 10:05:33 -0400 From: Rich Felker <dalias@...c.org> To: Natanael Copa <ncopa@...inelinux.org> Cc: "Gary E. Miller" <gem@...lim.com>, musl@...ts.openwall.com Subject: Re: *strerror_r() bug in musl On Wed, Apr 13, 2022 at 02:24:32PM +0200, Natanael Copa wrote: > On Tue, 12 Apr 2022 13:43:55 -0700 > "Gary E. Miller" <gem@...lim.com> wrote: > > > Yo All! > > Hi! > > > > > I'm new to the list. I;ve been trying to report a musl bug on #musl since > > last Friday, but no one seems to live there. > > > > musl (all versions) has a bug in strerror_r(). > > > > The musl reference manual says of _GNUSOURCE: > > > > _GNU_SOURCE (or _ALL_SOURCE) > > > > Adds everything above, plus interfaces modeled after GNU libc > > extensions and interfaces for making use of Linux-specific features. > > > > I take that to mean that when _GNU_SOURCE is used to compile code with musl > > that the results will behave as GNU libc (glinc). > > Well, as other has mentioned. GNU libc has a non-compliant version of > strerror_r. > > .... > > > 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 or, even better, wrapping strerror_r in a translation unit that begins with #undef _GNU_SOURCE #define _POSIX_C_SOURCE 200809L or similar so that you always get the standard one, and calling your wrapper instead. 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.