[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Forcing the use of 'int' version of strerror_r

From: Bob Friesenhahn
Subject: Re: Forcing the use of 'int' version of strerror_r
Date: Thu, 9 Dec 2004 09:39:37 -0600 (CST)

On Wed, 8 Dec 2004, Robert Lowe wrote:


I want to force the use of the POSIX version of strerror_r on systems
that have two versions.  On GNU/Linux, string.h has the following

My experience with Linux strerror_r (under Linux 2.6.7) is that its documentation (man page) is wrong, its behavior is broken, and playing with compilation options does not help. The glibc version always seems to return a char *, which is null if it fails.

You would be best served by using configure to learn how the default strerror_r behaves and adapting your code to suit.

You don't want to force -D_XOPEN_SOURCE=600 on all systems because behavior when the system does not support this level is undefined. In my experience, headers on some systems fail miserably if you specify an _XOPEN_SOURCE value greater than what they were designed to expect. Using -D_XOPEN_SOURCE=500 is reasonably safe on most (but not all) systems.

Trying to force the headers to behave a particular way seems to be a lost cause. After trying this approach for a number of months, I finally realized that relying on default behavior worked best.



/* Reentrant version of `strerror'.
  There are 2 flavors of `strerror_r', GNU which returns the string
  and may or may not use the supplied temporary buffer and POSIX one
  which fills the string into the buffer.
  To use the POSIX version, -D_XOPEN_SOURCE=600 or
  without -D_GNU_SOURCE is needed, otherwise the GNU version is
  preferred.  */

All I can find about the macro is:

If strerror_r is available, define HAVE_STRERROR_R, and if it is declared, define HAVE_DECL_STRERROR_R. If it returns a char * message, define STRERROR_R_CHAR_P; otherwise it returns an int error number. The Thread-Safe Functions option of POSIX requires strerror_r to return int, but many systems (including, for example, version 2.2.4 of the GNU C Library) return a char * value that is not necessarily equal to the buffer argument.

I'm not assuming that it would be safe to force -D_XOPEN_SOURCE=600
on all systems, for example, if STRERROR_R_CHAR_P is defined.  What
combination of tests would be recommended?  Only if $GCC is yes, and
STRERROR_R_CHAR_P is defined, or is there a test explicitly for
glibc?  Or something else?  Thanks for your patience... still feeling
a bit like I've gone down a rabbit hole, and there are way more options
at this tea party than I imagined.  ;-)


Autoconf mailing list

Bob Friesenhahn

reply via email to

[Prev in Thread] Current Thread [Next in Thread]