views:

92

answers:

1

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  A: 

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 effect (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().

Tim Post
What I don't understand is that in the documentation it says that `_POSIX_C_SOURCE=200112L` is defined by default ( see the edit to my OP ), so I don't understand why I'm getting the GNU version.
Robert S. Barnes
I tried the first one, and apparently something is turning it on. Nothing in my code is turning it on, so it must be something from either glibc, stdlib++ ( STL ) or Boost I assume. Is there a way to undef it globally from the command line?
Robert S. Barnes
@Robert - I don't believe glibc / stdlib++ turns extensions on by default. Its probably coming from boost, or another library. If your string header is included first (before boost), with `-D_POSIX_C_SOURCE`, it should be _off_. See my edit.
Tim Post
+1 So I guess that I'll need to try including `<cstring>` before any of the Boost headers and see if that helps and doesn't in the process break Boost.
Robert S. Barnes
I ran a test in which I checked `_GNU_SOURCE` as the very first statement in the file, and apparently it's defined by default by g++. The question is, will turning it off from the command line break stuff...
Robert S. Barnes
@Robert - In boost? I doubt it. Other stuff that isn't as well tested (or written) that does no fall back if common extensions aren't enabled .. its hard to say. The 'best' option might be to implement your own reentrant version of strerror(), which would not be that difficult. Then again, if nothing breaks .. no need to fix it :)
Tim Post
@Tim Post - No, not Boost, g++. I put the test as the first statement in the file before any `#include`'s. It seems like g++ is defining it.
Robert S. Barnes
@Robert - I mean that having it undefined would probably not break boost.
Tim Post