Glibc-ucontext.h中的错误，但仅在-std=c11时出现

我有一个最小的helloworld，扩展为包含

ucontext.h

：

#include <ucontext.h>
#include <stdio.h>

int main(int argc, char** argv) {
  printf ("hello world!\n");
  return 0;
}

我的第一个想法是glibc不支持c11。谷歌搜索这些信息并没有透露有用的信息。情况如何

---

（我将glibc-2.19与gcc-4.9一起使用。它是debian jessie，amd64。）

-std=c11

是c11标准兼容模式<代码>严格来说不是C11的一部分（参见Stas的答案）

要使用这些头文件，请使用扩展模式

-std=gnu11

，或根据要支持的平台定义适当的宏（

\u POSIX\u C\u SOURCE

，

\u BSD\u SOURCE

，

\u XOPEN\u SOURCE

，

\u GNU\u SOURCE

或其他）

关于功能启用宏。

似乎不推荐使用

函数，因为它们使用不推荐使用的C功能。因此，它们不能用于符合标准的C代码中。见：

将ISO/IEC 9899:1999标准纳入本标准 规范发现ISO C标准（第6.11.6款） 指定使用带空括号的函数声明符 是一种过时的功能。因此，使用功能原型：

void makecontext（ucontext\u t*ucp，void（*func）（），int argc，…）

正在利用ISO C标准的过时特征。 因此，严格符合POSIX标准的应用程序不能使用此选项 形式。因此，使用getcontext（）、makecontext（）和swapcontext（）可以 标志着过时

因此，它与C11没有直接关系。例如，我根本无法在MacOSX上用

clang

编译您的示例

它在C99标准中被弃用：

6.11.6函数声明器 使用带有空括号的函数声明符（不是原型格式参数类型声明符）是一种很好的方法 过时的特征

---

gcc-4.9应该与C11一起使用：@ChrisBeck Ok，但ucontext.h不是它的一部分，它是glibc2的一部分。可以在gcc 4.9.3和5.1.1GCC 5上复制这种行为。CC 5将C11设置为默认变量，所以常识告诉我glibc也应该完全支持它。你试过更新gcc/glibc吗？不，ucontext.h是posix的东西，不是BSD的东西，也不是XOPEN_源代码的东西。使用c11的目的正是为了使我的项目尽可能与标准兼容，使用这些预定义或gnu扩展将失去这个目标。@peterh c11不是POSIX。这些是不同的标准。是的。如果没有特定于生产者的扩展，glibc就不支持c11。我现在可以选择，我的项目是特定于BSD/XOPEN还是特定于gcc。@彼得你的说法没有任何意义。C11与posix无关。为什么说不支持posix头意味着不支持c11？@texasbruce它不支持c11模式下的posix头，因此c11、posix或编译器独立性将丢失。在我看来，这显然是一个glibc问题。这是非常不幸的，但无论如何，你都是。

$ gcc -std=c11 -c hw.c -Wall
In file included from /usr/include/ucontext.h:26:0,
                 from hw.c:1:
/usr/include/x86_64-linux-gnu/sys/ucontext.h:137:5: error: unknown type name ‘stack_t’
     stack_t uc_stack;
     ^