-4

C2x, 6.10.2 Source file inclusion, Semantics, 2 (emphasis added):

A preprocessing directive of the form

# include " q-char-sequence " new-line

causes the replacement of that directive by the entire contents of the source file identified by the specified sequence between the " delimiters.

C2x, 6.4.7 Header names, Syntax, 1:

header-name:
                 < h-char-sequence >
                 " q-char-sequence "

If q-char-sequence is about source file, then why the grammar doesn't have source-file-name?

Meaning that per grammar "x.c", "x.h", <x.c>, and <x.h> are all header-name. A bit confused.

pmor
  • 5,392
  • 4
  • 17
  • 36
  • 1
    Different operating systems have very different filename syntaxes, which the committee didn't want to try to standardize (didn't want to touch with a ten-foot pole, more like). So the stuff inside the `<…>` or `"…"` is just totally free-form as far as the Standard is concerned. – Steve Summit Feb 08 '22 at 13:00
  • 2
    Read a few lines down where `q-char` and `h-char` are defined. – dbush Feb 08 '22 at 13:01

2 Answers2

1

The grammar could not have been written

header-name: < source-file-name > | " source-file-name "
source-file-name: h-char-sequence | q-char-sequence

because that would allow either type of char-sequence to be used with either type of delimiter, and that would be incorrect, because the sequences are not the same. h-char-sequence does not allow > and q-char-sequence does not allow ".

If that's not your question then I don't understand what you want to know.

zwol
  • 135,547
  • 38
  • 252
  • 361
  • I want to know why `< h-char-sequence >` and `" q-char-sequence "` are both inside `header-name:`? Instead of `< h-char-sequence >` inside `header-name:` and `" q-char-sequence "` inside `source-file-name:`. – pmor Feb 15 '22 at 22:29
  • The tokenization rules in 6.4 are used in phase 3, at which point the only thing that matters is that either `< h-char-sequence >` or `" q-char-sequence "` is a valid header-name and therefore a valid pp-token. The rules in 6.10.x are used in phase 4, at which point the distinction between `<...>` and `"..."` inclusion does matter. Phases 3 and 4 are intertwined to some degree (note the prose in 6.4.7 about when header-name tokens are recognized) but 6.10.x not referring to header-name tokens causes no actual problems for implementers. – zwol Feb 15 '22 at 23:18
  • ... If I were given a free hand to revise the Standard I might well try to clean this up, but honestly it would be way down my list of priorities. This is only bad exposition -- what the semantics of the language actually are is not in question here, unlike some cases I can think of (*cough* "what is an object" fiasco). – zwol Feb 15 '22 at 23:24
  • Quick comment: yes, I see that some people (me too) wonder "what is an object". – pmor Feb 16 '22 at 01:13
  • @pmor https://stackoverflow.com/questions/47498585/is-adding-to-a-char-pointer-ub-when-it-doesnt-actually-point-to-a-char-arr/47499126#47499126 – zwol Feb 17 '22 at 20:45
1

The grammar only defines h-char-sequence and q-char-sequence as sequence of characters. It is up to the implementation to say which sequences are valid and how they are interpreted. The standards only adds the following constraint:

A #include directive shall identify a header or source file that can be processed by the implementation.

So using a sequence that would not not indentify a correct file should raise a compilation error.

The semantics part adds another requirement §5:

The implementation shall provide unique mappings for sequences consisting of one or more nondigits or digits (6.4.2.1) followed by a period (.) and a single nondigit. The first character shall not be a digit. The implementation may ignore distinctions of alphabetical case and restrict the mapping to eight significant characters before the period.

This ensures that the implementation will be able to accept the standard names like stdio.h and that a file having a name like foo.h has to be accepted, provided it maps to an existing file with the correct format.

Serge Ballesta
  • 143,923
  • 11
  • 122
  • 252
  • Minor correction: the sentence "A #include direcive shall specify..." appears in a "constraints" section, so breaking this rule does *not* lead to undefined behavior, but rather to mandatory issuance of a compile error. – zwol Feb 08 '22 at 13:24