From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 23707 invoked from network); 13 Apr 2022 20:38:52 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 13 Apr 2022 20:38:52 -0000 Received: (qmail 17628 invoked by uid 550); 13 Apr 2022 20:38:50 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 17596 invoked from network); 13 Apr 2022 20:38:49 -0000 Date: Wed, 13 Apr 2022 16:38:35 -0400 From: Rich Felker To: "Gary E. Miller" Cc: musl@lists.openwall.com Message-ID: <20220413203835.GW7074@brightrain.aerifal.cx> References: <20220412134355.59bd920e@spidey.rellim.com> <20220413142432.311e20f5@ncopa-desktop.lan> <20220413140532.GT7074@brightrain.aerifal.cx> <20220413103651.0087ca81@spidey.rellim.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220413103651.0087ca81@spidey.rellim.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] *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 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