What does it mean to include pthread.h with -std=c11?

[Carlos O'Donell <carlos at redhat dot com>]

In the recent bug 25271 [1] we had a situation where a user noticed
the following problem:

- When using -std=c11
- When including glibc's pthread.h.
- The glibc pthread.h headers were not self-consistent.

The issue sparked an interesting conversation between Andreas, Adhemerval,
and Florian about the validiation and QoI for such a situation.

The way I see it is that this used to work in glibc, I just checked an old
2.20 I have around and it was possible to include pthread.h, and get a
self-consistent set of headers that, in addition to ISO C11 support, also
included what was in pthread.h.

The question here is what do _really_ want to do in this case?

(1) Self-consistent set of headers.

The things defined in pthread.h, when in -std=c11, are not bound by any
standard definition, and so they are whatever we want to define. Yes,
a user may include their own pthread.h, but in this case the user is not,
and is included glibc's pthread.h.

Should we support making our headers self-consistent in this way?

(2) Unsupported behaviour.

Or should we declare that including a header from a standard that is outside
the expected standard set is not something we support?

If you include pthread.h, without POSIX support, you get an empty header,
and your code fails to build until you define the appropriate feature macro
to enable the definitions you want.

---

I'm on the fence here because it _used_ to work, and so it seems like at
some point we might have gone from (1) -> (2) without a deeper discussion
about exactly what kind of behaviour and maintenance responsibility we want
for these headers.

Thoughts?

-- 
Cheers,
Carlos.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=25271