Re: [PATCH v2] xfs_scrub: fix strerror_r usage yet again

["Darrick J. Wong" <djwong@kernel.org>]

On Thu, Sep 25, 2025 at 12:23:48AM -0700, Christoph Hellwig wrote:
> On Tue, Sep 23, 2025 at 05:53:53PM -0700, Darrick J. Wong wrote:
> > On Mon, Sep 22, 2025 at 10:01:17AM -0700, Christoph Hellwig wrote:
> > > The autoconf maigc looks good (as good as autoconf can look anyway),
> > > but why is this code using strerror_r to start with?  AFAIK on Linux
> > > strerror is using thread local storage since the damn of time, so
> > > just doing this as:
> > > 
> > > 	fprintf(stream, _("%s."), strerror(error));
> > > 
> > > should be perfectly fine, while also simpler and more portable.
> > 
> > But there's no guarantee that the implementation does this, is there?
> > The manpage doesn't say anything like that.
> 
> To me this pretty clear reads that the return string is stable until
> the next call to strerror as long as you only use it in the calling
> thread:
> 
> "The strerror() function returns a pointer to a string that describes
> the error code passed in the argument errnum,  ...
> This string must not be modified by the application, and the returned
> pointer will be invalidated on a subsequent call to strerror() or
> strerror_l(), or if the thread that obtained the string exits.  No
> other library function, including perror(3), will modify this string."

Huh, I don't see "...or if the thread that obtained the string exits" in
my version of the strerror(3) manpage on Debian 12.  For that matter, it
still lists strerror() as MT-Unsafe.

Looking through the manpages git repo, I see that strerror actually does
get changed to MT-Safe in commit 01576f703f820e54602:

    strerror.3: Change strerror() reference from MT-Unsafe to MT-Safe

    The information in this patch was obtained from a glibc upstream patch,
    commit 28aff047818eb1726394296d27b9c7885340bead ("string: Implement
    strerror in terms of strerror_l").

    According to the patch above, for glibc versions >=2.32, strerror() is
    MT-Safe.

    Signed-off-by: Shani Leviim <sleviim@redhat.com>

Then looking through the glibc repository, that 28aff047818e commit
comes from:

https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=28aff047818eb1726394296d27b9c7885340bead;hp=9deec7c8bab24659e78172dd850f4ca37c57940c

which turns strerror into strerror_l.  This commit only appears in glibc
2.32, which appeared in August 2020.  That version first appears in
Debian 12 and RHEL 9, which are still fairly new.  musl apparently has
had strerror call strerror_l since at least 2011.

Has strerror() been designated as thread-safe at a POSIX level, or is
this just an implementation quirk of these two C libraries?  strerror
definitely wasn't thread-safe on glibc when I wrote this program.

--D