[headers] is incomplete

[jwakely]

At least <stdatomic.h>, <stdbit.h> and <stdckdint.h> are not mentioned there.

Does this need an LWG issue?

[jwakely]

17.15 [support.c.headers] is mentioned in a footnote, and in p9, but there's no hint that [support.c.headers] includes new headers which don't correspond to anything in Table 25 [tab:headers.cpp.c].

Footnote 145 says "It is intentional that there is no C++ header for any of these C headers: <stdnoreturn.h>, <threads.h>" but doesn't mention that there are also no C++ headers for <stdatomic.h> etc.

Maybe we just want [headers] p9 to mention that [support.c.headers] has some additions, without going into details.

[jensmaurer]

Wait, <stdatomic.h> does exist in C++: [stdatomic.h.syn]

[jensmaurer]

The note in [support.c.headers.general] is now wrong, though:

[Note 1 : The C headers either have no effect, such as <stdbool.h> (17.15.5) and <stdalign.h> (17.15.4), or otherwise the corresponding header of the form provides the same facilities and assuredly defines them in namespace std. — end note]

[jwakely]

Wait, <stdatomic.h> does exist in C++: [stdatomic.h.syn]

Yes, that's my point. It's in the C++ standard library, but because there is no <cstdatomic> it's not mentioned at all in [headers]. It's mentioned in [support.c.headers] but [headers] seems to imply that [support.c.headers] only lists the name.h forms of C++ headers already mentioned in [headers]. That's no longer true, because we've added three headers that only have name.h forms and no cname form.

[frederick-vs-ja]

IMO it would make more sense to move some contents of [support.c.headers] into [headers], as all of these headers should be considered as C++ standard library headers. And it would be easier to maintain the specification if headers are nearly listed.