Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c > #6421

Re: Interaction between conditional inclusion and source file inclusion.

Show all headers | View raw

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On Saturday, December 25, 2021 at 11:52:06 AM UTC-5, Tim Rentsch wrote:
>
>> James Kuyper <james...@alumni.caltech.edu> writes:
>
> ...
>
>>> I've long understood that, during translation phase 4, as soon as
>>> a compiler reaches the new-line at the end of a #if directive, it
>>> knows whether the #if group will be included.  It not, and there's
>>> a corresponding #else, it knows that the #else group will be
>>> included.  Either way, as soon as it starts reading a group that
>>> will be included, it can immediately start preprocessing that
>>> group (and this is the important part:) while searching for the
>>> #else or #endif directive that terminates the group.
>>>
>>> I've also long understood that the #if, #else (if any) and #endif
>>> directives that make up an if-section must all occur in the same
>>> file.  I'm not sure how I reached that conclusion - it's not
>>> anything that the standard says explicitly.  [...]
>>
>> The first rule of grammar in 6.10 paragraph 1 says (with \sub()
>> to mean subscript)
>>
>> preprocessing-file:
>> group \sub(opt)
>>
>> Thus each preprocessing file must consist of an integral number
>> of group-part, and so cannot contain any unbalanced #if/#endif
>> directives, or any #else directive outside an #if/#endif section.
>
> I believe that what you're saying, using the terms defined in the C
> preprocessing grammar, is that neither an if-group, an else-group,
> nor a endif-line qualifies separately as a group-part, only a
> complete if-section can do so.

That isn't what I was saying, although I expect it is a true
statement.  What I was saying is that all the expansions of
group-part are balanced with respect to #if/#endif directives,
and also limit #else directives to be inside #if/#endif
segments.

> When the standard defines the meaning of a term, that definition
> takes precedence over any other interpretation you might reach by
> analyzing the meaning of the words making up that term.
> "preprocessing-file" is simply a symbol in the grammar - it's
> definition is the grammar rule associated with that symbol.

The possesive form of "it" is "its", with no apostrophe.  The
word "it's" is a contraction for "it is".

It may help to remember that the same rule applies to all
personal pronouns:  an apostrophe always indicates a
contraction with "am", "is" or "are" -

  I am, we are                   - I'm, we're
  you are                        - you're
  he is, she is, it is, they are - he's, she's, it's, they're

and there is never an apostrophe in the possessive form of a
personal pronoun -

  my, our
  your
  his, hers, its, their


> I've always interpreted the specification given in 6.10.2 as meaning
> that a given preprocessing file must match the grammar described in
> 6.10 up until the point that it recognizes a #include directive,
> which 'causes the replacement of that directive by the entire
> contents of the source file identified by the specified sequence
> between the " delimiters.' It's only the file after that replacement
> (and all other such replacements), which must fully parse in
> accordance with the grammar in 6.10.
>
> However, the term "preprocessing file" is also defined in 5.1.1.1p1.
> That's a section of the standard that seldom comes up in discussion,
> so I'd forgotten about that definition.  I agree that it makes sense
> that a "preprocessing file" is meant to match the syntax specified
> for a "preprocessing-file".  The standard often uses a grammar
> symbol name, with '-' replaced by spaces, to refer to things
> matching that grammar symbol.  However, this is one of the few
> places where the name, with that replacement, is formally defined
> separately from the grammar, implying a connection between those two
> definitions.

My reading of the C standard is that "preprocessing file",
"source file", and "preprocessing-file" all mean the same thing.
A #include directive (in the "" form) "shall identify a [...]
source file", and thus the content of the file being #include'd
must match the syntax of "preprocessing-file".

> This is not the clearest way to impose such a requirement.  If
> each preprocessing file is supposed to separately parse as a
> preprocessing-file, I think it would have been better to
> explicitly mention that fact in the description of 6.10.2
> "Source file Inclusion."  The "replacement" wording actually
> used gave me the strong impression that there were no content
> restrictions on the #included file itself, but only on the
> result after replacing the directive with those contents.

It seems other people don't have any problem understanding what
the requirements are here.  Do you have any ideas about why you
do when others don't?

Back to comp.std.c | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Interaction between conditional inclusion and source file inclusion. James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-12-25 01:18 -0500
  Re: Interaction between conditional inclusion and source file inclusion. Richard Damon <Richard@Damon-Family.org> - 2021-12-25 08:23 -0500
    Re: Interaction between conditional inclusion and source file inclusion. James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-12-25 11:09 -0500
  Re: Interaction between conditional inclusion and source file inclusion. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-25 08:52 -0800
    Re: Interaction between conditional inclusion and source file inclusion. James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-12-26 09:56 -0800
      Re: Interaction between conditional inclusion and source file inclusion. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-17 06:47 -0800

csiph-web