如何获取 POSIX strerror_r 而不是 GNU 版本? [英] How to get POSIX strerror_r instead of GNU version?

问题描述

我如何获得 POSIX strerror_r 而不是 GNU 版本?

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

我在 Ubuntu 8.04 上使用 g++ 和 glibc 2.7 版进行编译(基于其中的内容).

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

编辑

在上面的手册页上写着:

On the above man page it says:

glibc 的功能测试宏要求(参见 feature_test_macros(7)):

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.

然后在 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).

所以我应该得到 POSIX 版本，但我得到的是 GNU 版本.

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

推荐答案

从头文件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.  */

注意，使用 GNU 扩展时要小心，最后打开它们 (_GNU_SOURCE)，然后再包含您希望它影响的标头(或策略性地取消定义).不过，如果不使用 GNU 扩展，则无需担心.

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.

一般来说，如果 GNU 在默认行为中偏离 POSIX，您会在标题中看到一些注释来指示如何获得 POSIX 行为.它也(通常)记录在 glibc 手册中，但这并不总是能出现在高度浓缩的手册页中.

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.

编辑

试试这个简单的测试:

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

或者更直接

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

如果定义了 _POSIX_C_SOURCE={version}，则您应该拥有 POSIX 版本，除非其他原因导致 GNU 版本受到青睐.

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

我唯一能想到的就是_GNU_SOURCE.我确定这不在您的命令行标志上，您会看到它.可能是包含的另一个库已将其打开.

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.

这就是我在请求支持 POSIX 实现时扩展棘手"的意思，即使您不是打开它们的人.

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.

编辑

如果有东西打开了 _GNU_SOURCE(我不记得 boost 是否打开了，我使用 c++ 的次数几乎没有使用 C 的次数)，您可能希望允许它这样做.您可以从命令行使用 --undef "[macro]" -U[macro].但是，如果库代码如下所示，这将不起作用:

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;
}

问题是，当您的代码实际包含 string.h 时，其他东西已经打开了扩展并包含了它.包含警卫自然会阻止您将其包含两次.

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.

尝试明确关闭 _GNU_SOURCE 并在 anything 之前包含 string.h.这可以防止其他库打开这些扩展.但是，如果没有它们，这些库可能无法工作.有些代码只是预期"GNU 行为，不包括回退到 POSIX.

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.

我对没有 asprintf() 的库代码也有类似的挫败感.

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

这篇关于如何获取 POSIX strerror_r 而不是 GNU 版本?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！