Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
914 views
in Technique[技术] by (71.8m points)

ubuntu - 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.

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)

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


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...