“#define _GNU_SOURCE”是什么意思？意味着？

Question

今天我必须使用 basename() 函数和 man 3 basename (这里）给了我一些奇怪的消息：

注释

basename() 有两个不同的版本 - 上面描述的 POSIX 版本，以及 GNU 版本，后者是在 < /p>

#define _GNU_SOURCE
#include

我想知道这个 #define _GNU_SOURCE 意味着什么：它是否污染我用 GNU 编写的代码相关许可证？或者它只是用来告诉编译器类似“好吧，我知道，这组函数不是 POSIX，因此不可移植，但我还是想使用它”。

如果是这样，为什么不给人们不同的标头，而不是必须定义一些晦涩的宏来获得一个函数实现或另一个函数实现？

还有一些事情让我烦恼：编译器如何知道哪个函数实现与可执行文件链接？它也使用这个#define吗？

有人可以给我一些指示吗？

Answer 1

定义 _GNU_SOURCE 与许可证无关，与编写（非）可移植代码有关。如果您定义 _GNU_SOURCE，您将获得：

1. 访问许多非标准 GNU/Linux 扩展函数
2. 访问 POSIX 标准中省略的传统函数（通常有充分的理由，例如被更好的替代品替换） ，或与特定的遗留实现相关）
3. 访问无法移植的低级函数，但有时需要实现诸如 mount、ifconfig 等系统实用程序。
4. 许多 POSIX 指定函数的错误行为，其中 GNU 人员不同意标准委员会关于函数应如何运行的意见，并决定做自己的事情。

只要您了解这些事情，定义 _GNU_SOURCE 应该不是问题，但您应该避免定义它，而是定义 _POSIX_C_SOURCE=200809L 或 >_XOPEN_SOURCE=700 尽可能确保您的程序可移植。

特别是，您永远不应该使用 _GNU_SOURCE 中的内容是上面的 #2 和 #4。

Answer 2

有关 _GNU_SOURCE 启用的功能的确切详细信息，文档可以提供帮助。

来自 GNU 文档：

宏：_GNU_SOURCE

如果您定义此宏，则所有内容都将包括在内：ISO C89、ISO C99、POSIX.1、POSIX.2、BSD、SVID、X/Open、LFS 和 GNU 扩展。在 POSIX.1 与 BSD 冲突的情况下，POSIX 定义优先。

从 功能测试宏 上的 Linux 手册页：

_GNU_SOURCE

定义此宏（具有任何值）隐式定义
_ATFILE_SOURCE、_LARGEFILE64_SOURCE、_ISOC99_SOURCE、
_XOPEN_SOURCE_EXTENDED、_POSIX_SOURCE、_POSIX_C_SOURCE 以及
值 200809L（2.10 之前的 glibc 版本中为 200112L；
2.5 之前的 glibc 版本中为 199506L； glibc 版本中的 199309L
2.1 之前的版本）和 _XOPEN_SOURCE 的值为 700 (600
在 2.10 之前的 glibc 版本中； 500 之前的 glibc 版本
2.2）。此外，还提供了各种特定于 GNU 的扩展
暴露。

自 glibc 2.19 起，定义 _GNU_SOURCE 也具有以下效果
隐式定义 _DEFAULT_SOURCE。在 glibc 版本中
在 2.20 之前，定义 _GNU_SOURCE 也有以下效果
隐式定义 _BSD_SOURCE 和 _SVID_SOURCE。

注意：在包含头文件之前需要定义_GNU_SOURCE，以便各个头文件启用这些功能。例如：

#define _GNU_SOURCE

#include <stdio.h>
#include <stdlib.h>
...

还可以使用 -D 标志在每次编译时启用 _GNU_SOURCE：（

$ gcc -D_GNU_SOURCE file.c

-D 并非特定于 _GNU_SOURCE 但任何宏都可以这样定义）。

Answer 3

我再回答两点：

还有件事让我烦恼：编译器如何知道哪个函数实现与可执行文件链接？它也使用这个#define吗？

一种常见的方法是有条件地将 #define 标识符 basename 指定为不同的名称，具体取决于是否定义了 _GNU_SOURCE。例如：

#ifdef _GNU_SOURCE
# define basename __basename_gnu
#else
# define basename __basename_nongnu
#endif

现在库只需要在这些名称下提供这两种行为。

如果是这样，为什么不给人们不同的标头，而不是必须定义一些晦涩的环境变量来获取一个函数实现或另一个函数实现？

通常，相同的标头在不同的 Unix 版本中具有稍微不同的内容，因此没有单一的正确内容，例如 — 有许多标准 (xkcd)。
有一整套宏可供选择您最喜欢的宏，因此，如果您的程序需要一个标准，则该库将符合该标准。

Answer 4

来自谷歌的一些邮件列表：

看看glibc的include/features.h：

_GNU_SOURCE 以上所有内容，以及 GNU 扩展。

这意味着它可以实现这一切：

STRICT_ANSI、_ISOC99_SOURCE、_POSIX_SOURCE、_POSIX_C_SOURCE、
_XOPEN_SOURCE、_XOPEN_SOURCE_EXTENDED、_LARGEFILE_SOURCE、
_LARGEFILE64_SOURCE、_FILE_OFFSET_BITS=N、_BSD_SOURCE、_SVID_SOURCE

因此它为 gcc 启用了大量编译标志

Answer 5

为什么不给人们不同的标题

他们已经有了；标题按主题分为文件，因此需要另一个维度来过滤。

我正在寻找信号数字到名称的转换。我在 中找到了 strsignal()。手册页上写着：

sigabbrev_np(), sigdescr_np():
       _GNU_SOURCE                              <<< not default
strsignal():
       From glibc 2.10 to 2.31:
           _POSIX_C_SOURCE >= 200809L           <<< default, cf. XOPEN2K8 below
       Before glibc 2.10:
           _GNU_SOURCE

我从来没有真正关心过这部分。 sigabbrev_np() 不包含在默认“功能”中。 string.h 显示了如何：

#ifdef  __USE_XOPEN2K8
/* Return a string describing the meaning of the signal number in SIG.  */
extern char *strsignal (int __sig) __THROW;

# ifdef __USE_GNU
/* Return an abbreviation string for the signal number SIG.  */
extern const char *sigabbrev_np (int __sig) __THROW;
/* Return a string describing the meaning of the signal number in SIG,
   the result is not translated.  */
extern const char *sigdescr_np (int __sig) __THROW;
# endif

__USE_GNU 可以/应该通过 _GNU_SOURCE 在编译时或文件顶部进行设置。但这也会“激活”所有标头中的所有其他此类 ifdefed 声明。 （除非您为每个标头定义/取消定义）

因此，要显式导入仅一个（或其他）特殊函数，我现在这样做（复制粘贴。我留下了“THROW”并更改了“ __sig"):

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
extern const char *sigabbrev_np(int sig) __THROW;  /* __USE_GNU / _GNU_SOURCE */
#include <errno.h>
#include <elf.h>
#include <sys/ptrace.h>
#include <sys/wait.h>
...

现在 sigabbrev_np(wstate >> 8) 给我 TRAP 等，无需#defines。

我很难意识到 0x57f 意味着 OK，因为 5 是 TRAP，但是 0xb7f 和 0x77f 是 SEGV 和 BUS --- 我得到的取决于我设置断点的位置，有时是在数千条指令之后。因为我没有后退指令指针......