What is the purpose of a "non-directive"?
Keith Thompson
group-part:
if-section
control-line
text-line
# non-directive
...
non-directive:
pp-tokens new-line
...
pp-tokens:
preprocessing-token
pp-tokens preprocessing-token
new-line:
the new-line character
The only statements made about "non-directives" are:
A non-directive shall not begin with any of the directive names
appearing in the syntax.
and a footnote:
Despite the name, a non-directive is a preprocessing directive.
The footnote appears in N1256 and TC2, not in the original C99
standard. It, and the brief discussion in the Rationale, were added
in response to DR 231
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_231.htm>, the
response to which was:
The standard is correct, but provide the following words with the
response, and include them in the Rationale document:
Neither text-line nor non-directive is implementation
defined. They are strictly defined as sequences of pp-tokens
followed by new-line. Each of these rules represents a
placeholder for an intermediate state in the phases of
translation, and is expressed as a non-terminal since it has
no associated semantics at this phase.
However, these sequences of pp-tokens are still subject to
normal processing in the subsequent phases of translation.
So what exactly *is* a "non-directive", what is its purpose?
If I'm reading the grammar correctly (and it's very likely I'm not),
then in the following:
#define SOME_SYMBOL
#undef SOME_OTHER_SYMBOL
#include <stdio.h>
int main(void)
{
#ifdef SOME_SYMBOL
puts("Hello, world");
#elsif defined SOME_OTHER_SYMBOL
puts("Goodbye, world");
#endif
return 0;
}
then "elsif defined SOME_OTHER_SYMBOL" is a non-directive (the correct
spelling is "elif").
If a non-directive is supposed to be ignored, then the output of the
program should be:
Hello, world
Goodby, world
and misspellings of directive names would be a rich source of bugs.
If it's supposed to be diagnosed as a syntax error, I don't see where
the standard says so.
If the behavior is supposed to be undefined (since I see no definition
of the behavior), that's probably even worse.
What is the intent, and why doesn't the standard express that intent
more clearly?
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Tim Rentsch
Yes, the '#eslif' line is a 'non-directive' preprocessing directive.
> If a non-directive is supposed to be ignored, then the output of the
> program should be:
> Hello, world
> Goodby, world
> and misspellings of directive names would be a rich source of bugs.
It may be ignored but is not required to be.
> If it's supposed to be diagnosed as a syntax error, I don't see where
> the standard says so.
It's not a syntax error. Having a non-directive in ones
program source is neither a syntax error nor a constraint
violation.
> If the behavior is supposed to be undefined (since I see no definition
> of the behavior), that's probably even worse.
Yes, it is. Wonderful, eh? But since there is no explicit
definition of what behavior occurs when a 'non-directive'
is executed, the behavior is undefined.
> What is the intent, and why doesn't the standard express that intent
> more clearly?
The reason for having 'non-directive' is to make any line
starting with '#' a preprocessing directive, even if it
doesn't have one of the regular keywords at the beginning.
The motivation for giving no specification for its behavior
is (I presume) so implementatons may define their own
proprocessing directives without running afoul of any
semantic restrictions.
The defense for making the behavior undefined (rather than
having it require a diagnostic, or be implementation-defined,
or something else...) is so implementations can deal with
'non-directive's as elaborately or as simply as they choose
(maybe there were some historical precedents?) and not
violate the standard. Then how different implementations
handle non-directives is a QOI question.
Personally, except for clarifying that a line starting with
'#' is a preprocessing directive even if it doesn't start
with one of the regular PP keywords, I think the definition
of 'non-directive' is lacking in terms what semantics are
specified for it, why they should be the way they are, and
how clearly the current semantics (ie, UB) are expressed.
I think it should at least be implementation-defined as to
what 'non-directive's an implementation defines, and a
constraint violation if any other 'non-directive' appears
in any unskipped program source. It might be nice also to
say what different implementation-defined non-directives
actually do, but at least tell us which ones are legal and
which ones are not, and require any non-legal ones to give
a diagnostic. Yow.
Keith Thompson
> Keith Thompson <ks...@mib.org> writes:
[...]
>> What is the intent, and why doesn't the standard express that intent
>> more clearly?
>
> The reason for having 'non-directive' is to make any line
> starting with '#' a preprocessing directive, even if it
> doesn't have one of the regular keywords at the beginning.
>
> The motivation for giving no specification for its behavior
> is (I presume) so implementatons may define their own
> proprocessing directives without running afoul of any
> semantic restrictions.
Just to be clear, are you saying definitely that this was the intent
of the committee?
Tim Rentsch
> Tim Rentsch <t...@alumni.caltech.edu> writes:
>> Keith Thompson <ks...@mib.org> writes:
> [...]
>>> What is the intent, and why doesn't the standard express that intent
>>> more clearly?
>>
>> The reason for having 'non-directive' is to make any line
>> starting with '#' a preprocessing directive, even if it
>> doesn't have one of the regular keywords at the beginning.
>>
>> The motivation for giving no specification for its behavior
>> is (I presume) so implementatons may define their own
>> proprocessing directives without running afoul of any
>> semantic restrictions.
> [...]
>
> Just to be clear, are you saying definitely that this was the intent
> of the committee?
I am saying definitely that I /believe/ this was the intent
of the committee. I don't have special knowledge that
would allow me to say that it definitely is (or was)
the actual intent. But I believe it was, based on
general public knowledge of the people and processes
involved.