4

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?

pmor
  • 5,392
  • 4
  • 17
  • 36
  • I would say if the implementation has `stdatomic.h` (7.17.1.2), then it will not have the restriction to 8 characters. Well, if it is a sane implementation. – Eugene Sh. Feb 23 '21 at 16:18
  • The translation limits of C have always been haywire. The standard specifies an utter minimum but useful compilers in practice go way beyond that minimum. C90 had "6 significant initial characters in an external identifier" which just makes you want to scream "what were they thinking!!!" This text quoted here is also from the C90 days. There's no rationale for it, they simply weren't thinking with their brains when they set these limits. – Lundin Feb 24 '21 at 13:05
  • 1
    Funny though, C90 restricted includes to 6 characters, then C99 extended it to 8. – Lundin Feb 24 '21 at 13:10

2 Answers2

3

If you're using #include <stdatomic.h> then the library header shall be included. But it is free to do the same (or not) with #include <stdatomi.h> or #include <stdatomix.h>

However #include <stdatom.h> shall be treated as a different file. But on the other hand, there's nothing that explicitly forbids an implementation to have a file stdatom.h which only content is #include <stdatomic.h>. Not that any implementation would do it, but it is allowed.

There's no real contradiction here. Just a funny consequence.

klutt
  • 30,332
  • 17
  • 55
  • 95
  • The standard says: _A #include directive shall identify a header or source file that can be processed by the implementation_. I.e. _shall_, not _should_. – pmor Feb 24 '21 at 20:49
  • @pmor That's just about tempus. I cannot see that it would make any difference. Or? – klutt Feb 24 '21 at 21:10
  • The standard (e.g. ISO/IEC 9899:202x (E)) makes clear difference. Quote from `4. Conformance`: _In this document, "shall" is to be interpreted as a requirement on an implementation or on a program; conversely, "shall not" is to be interpreted as a prohibition._ See also: https://stackoverflow.com/a/6565606/1778275. – pmor Feb 24 '21 at 21:36
  • @pmor Fair enough. Didn't know that. Thanks, I've fixed it now. – klutt Feb 25 '21 at 06:17
1

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.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
  • 1. The standard says: _The implementation may ... restrict the mapping ..._ You say: _it's not a restriction ... on implementations_. I am confused. Can you elaborate? 2. Then why not all the standard headers are preceded with `std` prefix (e.g. why `assert.h` and not `stdassert.h`)? – pmor Feb 24 '21 at 20:36
  • @pmor, it's not a restriction *on implementations*. It's a restriction on the behaviors that programs can rely upon implementations to provide. It grants implementations the freedom to either distinguish between `stdatomic.h` and `stdatomix.h` or not, as they choose. More options is not a restriction relative to fewer options. – John Bollinger Feb 24 '21 at 20:48
  • Consider an implementation (C compiler) running under OS with FS that supports filename with max. 8 characters before the period. What exactly will happen for `#include `? Will such implementation be aware of the properties of underlying FS and, for, example, map `stdatomic.h` to, say, `x1v3J_Ko.h` (any sequence of 8 characters, which is very unlikely appears in the user space), which is the filename for file with the content of `stdatomic.h`? I.e. how such implementation will provide a guarantee that `stdatomic.h` will be included despite of the limitation of the underlying FS? – pmor Feb 24 '21 at 21:32
  • @pmor, an implementation can do whatever it wants or needs to do to conform, in that or any other case. In particular, do note that standard library header names are not required to be the names of actual files on any filesystem. Note further that 6.10.2.5 is an *enabler*: it allows simple implementations of C on filesystems such as you describe. That it does so does not itself constrain any implementation -- if there is a constraint in that area then it is imposed by the host environment, not by C. None of that conflicts with this answer. – John Bollinger Feb 24 '21 at 21:45
  • @pmor: The natural thing for it to do is truncate the names. So the header would live in the file `stdatomi.h` on the filesystem, and including any of ``, ``, ``, or `` would include it. – Nate Eldredge Feb 25 '21 at 06:28
  • @pmor: The ones that don't start with `std` are mainly those that appeared in earlier versions of the standard, to conform to traditional behavior or simply before the committee decided to get serious about sticking to the `std____` convention. – Nate Eldredge Feb 25 '21 at 06:30