Glibc - error in ucontext.h, but only with -std=c11

Question

I have this minimal helloworld, extended with an include of ucontext.h:

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

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

It compiles without warning with gcc-4.9 (gcc -c hw.c -Wall).

But if I switch to the c11 standard (gcc -std=c11 -c hw.c -Wall), I get the following error:

$ 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;
     ^

My first idea is that glibc doesn't support c11. Googling for that didn't reveal usable information. What is the case?

(I use glibc-2.19 with gcc-4.9. It is a debian jessie, amd64.)

gcc-4.9 should work with C11: https://gcc.gnu.org/wiki/C11Status — Chris Beck, Sep 06 '15 at 18:29
@ChrisBeck Ok, but ucontext.h isn't part of it, it is part of glibc2. — peterh, Sep 06 '15 at 18:29
[http://stackoverflow.com/questions/20778735/is-the-type-stack-t-no-longer-defined-on-linux](http://stackoverflow.com/questions/20778735/is-the-type-stack-t-no-longer-defined-on-linux) — 4566976, Sep 06 '15 at 18:30
GCC 5 has C11 set as default variant, so common sense tells me that glibc should also fully support it. Have you tried updating gcc/glibc? — Luke, Sep 06 '15 at 18:31
@Luke ucontext.h isn't part of the gcc, it is in the glibc, which is a different project with maybe different standard compatibility. — peterh, Sep 06 '15 at 18:31
One would expect that GNU maintains their projects with same/similar priority, especially because they aim to make GCC self-hosting (one day) — Luke, Sep 06 '15 at 18:36
Where/how is `stack_t` declared, where defined? As others already stated, it is not C11, so there might be a problem with the header. — too honest for this site, Sep 06 '15 at 18:40
@Olaf I think it could be an internal thing of the headers. The problem is that the posix big dogs don't like the userspace context switching and thus ucontext is going to be eliminated. I like it, and thus posix compliance isn't a goal to me any more. — peterh, Sep 07 '15 at 01:51
@Luke It goes with -std=gnu11, only -std=c11 harms everything. This breaks posix compliance, but my preferences meanwhile changed and so it is not a problem any more. Btw, what do you understand on "self-hosting gcc"? If you think to the ability to compile itself, it is capable to do that since around 1985. — peterh, Sep 07 '15 at 01:53

milleniumbug · Accepted Answer · 2015-09-06T18:58:46.780

4

-std=c11 is C11 standard compliant mode. <ucontext.h> isn't strictly part of C11 (see Stas's answer).

To use these headers either use extension mode -std=gnu11 or define appropriate macro depending on which platform do you intend to support (_POSIX_C_SOURCE, _BSD_SOURCE, _XOPEN_SOURCE, _GNU_SOURCE or maybe others).

See this page for more info about feature-enabling macros.

edited Sep 06 '15 at 18:58

answered Sep 06 '15 at 18:34

milleniumbug

15,379
3
47
71

No, ucontext.h is a posix thing, not BSD thing and also not XOPEN_SOURCE thing. The goal of using c11 was exactly to make my project as standard-compatible as possible, this goal will be lost with these predefines or by the gnu extension. – peterh Sep 06 '15 at 18:37
@peterh C11 is not POSIX. These are different standards. – milleniumbug Sep 06 '15 at 18:38
Yes. Then glibc doesn't support c11 without producer-specific extensions. I can now choose, if my project will be BSD/XOPEN-specific, or it will be gcc-specific. – peterh Sep 06 '15 at 18:39
@peterh Your statement does not make any sense. C11 has nothing to do with posix. Why do you say not suppporting posix header means not supporting c11? – SwiftMango Sep 06 '15 at 18:40
@texasbruce It doesn't support posix header in c11 mode, thus either c11, or posix, or compiler-independence will lost. It is clearly glibc problem, on my opinion. – peterh Sep 06 '15 at 18:42
And gcc has nothing to do with posix. Even you choose "gcc specific", it doesn't mean it support posix and not supporting BSD – SwiftMango Sep 06 '15 at 18:43
@peterh What. That's the wrong conclusion. You clearly instructed the compiler to not take any extensions *to C11*. As far as C11 is concerned, POSIX is such an extension. If you want POSIX conformance, **say so** by declaring appropriate macro. (I'm not aware of POSIX specific macros, [but `_XOPEN_SOURCE` includes POSIX according to the accepted answer in this](http://stackoverflow.com/questions/5378778/what-does-d-xopen-source-do-mean)) – milleniumbug Sep 06 '15 at 18:45
@texasbruce No, I want to compile c11-compliant _and_ posix-compliant code, this is what can't be done with gcc/glibc. – peterh Sep 06 '15 at 18:49
@peterh They ARE independent from each other. And gcc DOES support posix as well as BSD with extension (in C11 or not). The standard you choose is not the same as what extension you choose. My last comment here. – SwiftMango Sep 06 '15 at 18:50
@peterh You could `#define _POSIX_C_SOURCE 200809L`, doesn't that look posix-compliant? – 4566976 Sep 06 '15 at 20:04
If you do, it will definitely not work as ucontext.h has been removed on POSIX issue 7. – schily Sep 06 '15 at 21:10
@texasbruce Ok, then how could I use both of them? It is only a theoretical question, I am now disappointed from posix because of their tendency to harm the context support. So I compile everything with -std=gnu11. – peterh Sep 07 '15 at 01:47
@schily Thanks the warning. – peterh Sep 07 '15 at 01:48
@4566976 Yes, it looks posix-compliant. – peterh Sep 07 '15 at 01:48

Stas · Answer 2 · 2015-09-06T18:58:46.870

It seems <ucontext.h> functions are deprecated, because they use deprecated C feature. So they can't be used in standard compliant C code. See the rationale:

With the incorporation of the ISO/IEC 9899:1999 standard into this specification it was found that the ISO C standard (Subclause 6.11.6) specifies that the use of function declarators with empty parentheses is an obsolescent feature. Therefore, using the function prototype:

void makecontext(ucontext_t *ucp, void (*func)(), int argc, ...);

is making use of an obsolescent feature of the ISO C standard. Therefore, a strictly conforming POSIX application cannot use this form. Therefore, use of getcontext(), makecontext(), and swapcontext() is marked obsolescent.

So, it is not directly related to C11. For example, I can't compile your example with clang on Mac OS X at all.

It was deprecated in C99 standard:

6.11.6 Function declarators

The use of function declarators with empty parentheses (not prototype-format parameter type declarators) is an obsolescent feature.

It is highly unfortunate, but that you anyways. – peterh Sep 07 '15 at 01:56 — peterh, Sep 07 '15 at 01:56

Glibc - error in ucontext.h, but only with -std=c11

2 Answers2

Linked