How to get POSIX strerror_r instead of GNU version

问题:

How do I get the POSIX strerror_r instead of GNU version?

I'm compiling with g++ on Ubuntu 8.04 with glibc version 2.7 ( based on what's in ).

Edit

On the above man page it says:

Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

   The XSI-compliant version of strerror_r() is provided if:
   (_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && ! _GNU_SOURCE
   Otherwise, the GNU-specific version is provided.

It then says in feature_test_macros(7):

   If no feature test macros are explicitly defined, then the following feature
   test macros are defined by default: _BSD_SOURCE, _SVID_SOURCE, _POSIX_SOURCE,
   and _POSIX_C_SOURCE=200809L (200112L in glibc versions before 2.10; 199506L in
   glibc versions before 2.4; 199309L in glibc versions before 2.1).

So I should be getting the POSIX version, but I'm getting the GNU one instead.

回答1:

From the header string.h:

/* 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 -D_POSIX_C_SOURCE=200112L
   without -D_GNU_SOURCE is needed, otherwise the GNU version is
   preferred.  */

Note, be careful when using GNU extensions, turn them on (_GNU_SOURCE) last, before including the headers that you want it to affect (or undefine it strategically). No need to worry if not using GNU extensions, though.

Generally, if GNU deviates from POSIX in default behavior, you'll see some comments in the header to indicate how you can get the POSIX behavior. Its also (usually) documented in the glibc manual, but that doesn't always make it to the highly condensed man pages.

Edit

Try this simple test:

#include <string.h>
#ifdef _GNU_SOURCE
#error "Something turned it on!"
#endif

Or more directly

#ifdef _GNU_SOURCE
#undef _GNU_SOURCE
#endif
#include <string.h>

If _POSIX_C_SOURCE={version} is defined, you should have the POSIX version unless something else caused the GNU version to be favored.

The only thing I can think of that would do that is _GNU_SOURCE. I'm sure this isn't on your command line flags, you would have seen it. It could be that another library that is included has turned it on.

That's what I meant about the extensions being 'tricky' when requesting that POSIX implementations be favored, even if you aren't the one turning them on.

Edit

If something is turning on _GNU_SOURCE (I can't recall if boost does or not, I don't use c++ nearly as much as I do C), you probably want to allow it to do so. You can use --undef "[macro]" -U[macro] from the command line. However, that won't work if the library code looks like this:

#ifndef _GNU_SOURCE
#define _GNU_SOURCE
#endif

#include <stdio.h>
#include <string.h>

#ifdef _GNU_SOURCE
#error "It didn't work"
#endif

int main(void)
{
   return 0;
}

The issue is, by the time your code actually includes string.h, something else has already turned on extensions and included it. Include guards naturally prevent you from including it twice.

Try explicitly turning off _GNU_SOURCE and including string.h prior to anything else. This prevents other libraries from turning those extensions on. However, those libraries might not work without them. Some code just 'expects' GNU behavior, and does not include fallback to POSIX.

I've experienced similar frustration with library code that does not work without asprintf().

回答2:

While it's not required to be thread-safe by the standard, I can't imagine any way a sane person could write a non-thread-safe strerror. What do people do, gunzip the error strings at runtime or something?! A good strerror should be returning a pointer either to string constants in the standard library, or to constant mmap'd memory from the locale messages file.

Apologies that this isn't a real answer, but if you don't care about absolute theoretical portability you might check and see if all the implementations you care about have sane strerror behavior, and if so, just use that instead.

回答3:

This is an implementation-specific workaround.

#ifdef __cplusplus
extern "C"
    {
#endif
    extern 
    int __xpg_strerror_r(int errcode,char* buffer,size_t length);
    #define strerror_r __xpg_strerror_r

#ifdef __cplusplus
    }
#endif