如何获取 POSIX strerror_r 而不是 GNU 版本？

Question

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

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

编辑

在上面的手册页上写着：

glibc 的功能测试宏要求（参见 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 版本。

Answer 1

来自标题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 扩展，则无需担心。

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

编辑

试试这个简单的测试：

#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 版本受到青睐。

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

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

编辑

如果 _GNU_SOURCE 正在开启某些东西（我不记得 boost 是否开启，我使用 c++ 的次数几乎没有使用 C 的次数），您可能希望允许它这样做。您可以从命令行使用--undef "[macro]" -U[macro]。但是，如果库代码如下所示，这将不起作用：

#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 时，其他东西已经打开了扩展并包含了它。包含警卫自然会阻止您将其包含两次。

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

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

Answer 2

这是一个特定于实现的解决方法。

#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

Answer 3

虽然标准并不要求它是线程安全的，但我无法想象一个理智的人会以任何方式编写非线程安全的strerror。人们在做什么，gunzip 运行时的错误字符串之类的？！一个好的 strerror 应该返回一个指向标准库中的字符串常量的指针，或者从语言环境消息文件返回一个指向常量 mmap 的内存。

抱歉，这不是一个真正的答案，但如果您不关心绝对的理论可移植性，您可以检查并查看您关心的所有实现是否具有健全的 strerror 行为，如果是，请使用它而是。