Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 8 Feb 2013 13:59:18 -0500
From: Rich Felker <>
Subject: Re: guard bug for strerror_r

On Fri, Feb 08, 2013 at 10:01:25AM -0800, Isaac Dunham wrote:
> On Fri, 08 Feb 2013 18:30:00 +0100
> Jens Gustedt <> wrote:
> > 
> > __GNU_SOURCE is defined by the gnu platform to specify the
> > availability of their extensions. Unfortunately they don't have a
> > finer grained tool to distinguish different types of extensions they
> > provide. (BTW the same holds for gcc, that you only can tune with
> > version numbers.)
> > 
> > If I, as a user, define __GNU_SOURCE I expect to have the gnu
> > extension, if I then use strerror_r I expect to have their interface,
> > since this is documented like this. At least as it is now, I don't
> > think I have any means to distinguish the two platforms and to know
> > which version of strerror_r I would receive.
> #ifdef __linux
> #include <features.h> /* this is partly for this purpose */

Use <stdlib.h> or similar -- it will include <features.h>, but it's
standard, so it won't break on systems that don't have it.

> /*including <unistd.h> would also work, and is more universal
> * it's actually necessary with dietlibc, IIRC */
> #if defined(__GLIBC__) && defined(__USE_GNU)
> ...

I would simply avoid _ever_ using strerror_r on GNU systems. On any
modern GNU or POSIX 2008 conforming system, you have the vastly
superior strerror_l function. It does not require you to provide a
buffer, and it's thread-safe (the buffer returned is either immutable
static or thread-local). The logic I'd recommend is:

#if _POSIX_VERSION >= 200809L || defined(__GLIBC__)
/* use strerror_l */
/* use strerror_r and assume POSIX version of it */


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.