ISO/IEC 9899:2011 (E):
6.10.2.5
The implementation may ignore distinctions of alphabetical case and restrict the mapping to eight significant characters before the period.
Since stdatomic.h
has 9 characters before the period, does it make a contradiction with the (potential) restriction above? I.e. that some implementations will not distinguish between stdatomic.h
and (for example) stdatomix.h
when using them as argument for #include
directive?
Extra question: why stdatomic.h
and not atomic.h
?
The implementation may ignore distinctions of alphabetical case and restrict the mapping to eight significant characters before the period.
Since stdatomic.h has 9 characters before the period, does it make a contradiction with the (potential) restriction above?
No, because although it uses the word "restrict", it's not a restriction on the language or on implementations. It's a freedom granted to implementations.
I.e. that some implementations will not distinguish between stdatomic.h and (for example) stdatomix.h when using them as argument for #include directive?
That an implementation did not distinguish between those two as include file names would not make it fail to conform in any way. The standard specifies particular significance for include directives of the form
#include <stdatomic.h>
. As long as the implementation recognizes that directive and gives it the required significance, it is of no consequence with respect to the standard whether
#include <stdatomix.h>
is given the same significance.
Extra question: why stdatomic.h and not atomic.h?
It is a common convention, albeit not a universally observed one, to prefix the names of standard library headers with "std". Other examples include stdalign.h
, stdarg.h
, stdbool.h
, stddef.h
, stdint.h
, stdio.h
, stdlib.h
and stdnoreturn.h
. I am uncertain about the committee's policy on this, but certainly one of the effects is to reduce the likelihood that the name of a new header added to the standard library collides those of headers used by existing projects.