"error: invalid preprocessing directive #DEFINE"
alien
2:2: error: invalid preprocessing directive #DEFINE
Why, and how do i fix it?
Malcolm McLean
"alien" <anders....@gmail.com> wrote in message
news:f8fc0570-9e1a-4cf0...@j9g2000vbp.googlegroups.com...
> When i'm trying to compile a program with #DEFINE it says:
> 2:2: error: invalid preprocessing directive #DEFINE
>
> Why, and how do i fix it?
Somehow you must have got a c source file from an oddball system that
doesn't have lower case.
Eric Sosman
Try #define.
(Language lawyers: Was his compiler justified in
rejecting his code, assuming that it did? See 6.10,
fourth production of group-part; the Standard says very
little about this topic.)
--
Eric Sosman
eso...@ieee-dot-org.invalid
kr0wie
> "alien" <anders.refsl...@gmail.com> wrote in message
Okay. It works with #define, thanks for the quick answer.
Joe Wright
C is case sensitive. It is #define that you want.
--
Joe Wright
"If you rob Peter to pay Paul you can depend on the support of Paul."
Richard Heathfield
> alien wrote:
>> When i'm trying to compile a program with #DEFINE it says:
>> 2:2: error: invalid preprocessing directive #DEFINE
>>
>> Why, and how do i fix it?
>
> Try #define.
>
> (Language lawyers: Was his compiler justified in
> rejecting his code, assuming that it did? See 6.10,
> fourth production of group-part; the Standard says very
> little about this topic.)
If not, then # becomes a rather odd but perfectly legal line-comment
character, with the added spice that not all comments are legal.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Seebs
STOP SHOUTING AT YOUR COMPILER.
-s
p.s.: No, really. This is the correct answer to your question.
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Tim Rentsch
> alien wrote:
>> When i'm trying to compile a program with #DEFINE it says:
>> 2:2: error: invalid preprocessing directive #DEFINE
>>
>> Why, and how do i fix it?
>
> Try #define.
>
> (Language lawyers: Was his compiler justified in
> rejecting his code, assuming that it did? See 6.10,
> fourth production of group-part; the Standard says very
> little about this topic.)
My reading is that
#DEFINE <pp-tokens> <new-line>
(which presumably is what was there) is legal, and should not
have been rejected.
Kenneth Brody
Based on what? Section 6.10 clearly shows several varations on "#define",
but all are listed with lowercase "define", and I see nothing which states
or implies case insignificance.
--
Kenneth Brody
jameskuyper
Based upon 6.10p1, the production covering "# non-directive". Since
DEFINE satisfies the requirements for a pp-token, "DEFINE pp-tokens
new-line" matches the requirements for a "non-directive". The only
requirement imposed upon a non-directive is that it "shall not begin
with any of the directive names appearing in the syntax." (6.10p3).
DEFINE is definitely not one of those directive names.
It might seem that the standard defines no behaviour for non-
directives; if that were the case, then the behaviour would be
undefined by reason of the absence of a definition.
However, there's a tricky argument that can be made that the behavior
IS defined, though in a very minimalist way. The only other thing the
standard says about non-directives is to point out, in footnote 150,
that "Despite the name, a non-directive is a preprocessing
directive.". While non-normative, that note merely confirms what can
already be inferred from the normative grammar productions in 6.10p1.
Because a non-directive is a preprocessing directive, 5.1.1.2p4
applies, which says that at the end of translation phase 4 "All
preprocessing directives are then deleted." Arguably, this defines the
behaviour of non-directives: they exist, like comments, solely for the
purpose of being removed without having any actual effect on the
translation of the program.
I'm not happy with this argument; I'd prefer a direct statement that
non-directives are simply to be ignored.
Tim Rentsch
6.4.2.1p2, "Lowercase and uppercase letters are distinct."
Tim Rentsch
Sorry, I answered the wrong sense of your question earlier.
Given that case is significant, my statement was based on (a) syntax
rules in 6.10p1, specifically for 'group-part:' and 'non-directive:',
(b) the second sentence in 6.10p3 ('DEFINE' is different from
'define'), and (c) the reassurance given in the footnote in 6.10.3p11.
The counter-argument is that, since there is no explicit definition
of behavior for a 'non-directive', the behavior is undefined. I don't
have any substantial defense to offer in response to this argument
(my previous checking wasn't thorough enough). Given that, I withdraw
my previous statement, and now venture to say that, since there is
no explicit definition of behavior, the compiler is within its
rights to do whatever it chooses, including rejecting the program.
Keith Thompson
I'd be even happier with a direct statement that non-directives
require a diagnostic, like any syntax error.
If I can write
#defnie SOME_IMPORTANT_SYMBOL
or
and have the compiler silently ignore it, that's not a good thing.
Similarly, if I write:
#if SOME_CONDITION
this_code;
#elsif SOME_OTHER_CONDITION
that_code;
#endif
and both this_code and that_code are executed (because I typed
"#elsif" rather than "#elif"), that could lead to some bugs that
are very difficult to track down.
There's very little discussion of them in the Standard. The Rationale
has this to say (6.10):
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.
which is less than illuminating. If it were the intent that
non-directives are ignored, I presume the standard would say so,
as it does for the null directive.
I'll post to comp.std.c in the vague hope of catching the attention
of someone who can explain the actual intent.
--
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"
Willem
) I'd be even happier with a direct statement that non-directives
) require a diagnostic, like any syntax error.
How about making it implementation-defined behaviour ?
Then you can read the docs of the compiler and be sure that it doesn't
silently ignore those typoes.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
Keith Thompson
> Keith Thompson wrote:
> ) I'd be even happier with a direct statement that non-directives
> ) require a diagnostic, like any syntax error.
>
> How about making it implementation-defined behaviour ?
> Then you can read the docs of the compiler and be sure that it doesn't
> silently ignore those typoes.
Just from a usability point of view, how would making it
implementation-defined be better than a mandatory diagnostic?
If I misspell a keyword, I get a diagnostic. If I misspell a
preprocessor directive name, I want the same thing. (And that's
what I get on the two compilers I tried.)
Kenneth Brody
> Kenneth Brody wrote:
>> Tim Rentsch wrote:
>>> My reading is that
>>>
>>> #DEFINE <pp-tokens> <new-line>
>>>
>>> (which presumably is what was there) is legal, and should not
>>> have been rejected.
>> Based on what? Section 6.10 clearly shows several varations on "#define",
>> but all are listed with lowercase "define", and I see nothing which states
>> or implies case insignificance.
>
> Based upon 6.10p1, the production covering "# non-directive". Since
> DEFINE satisfies the requirements for a pp-token, "DEFINE pp-tokens
> new-line" matches the requirements for a "non-directive". The only
> requirement imposed upon a non-directive is that it "shall not begin
> with any of the directive names appearing in the syntax." (6.10p3).
> DEFINE is definitely not one of those directive names.
> I'm not happy with this argument; I'd prefer a direct statement that
> non-directives are simply to be ignored.
While I agree with what you said for the most part, I would have to say that
allowing "anything" as a "non-directive" (which I agree the Standard says is
the case) to "simply be ignored" would be "A Bad Thing[tm]". Consider what
happens with a simple typo:
#defien SOME_CONFIG_FLAG 1
or
#if USE_VERSION == 1
... first version of the code ...
#elseif USE_VERSION == 2
... second version ...
#else
... default version ...
#endif
or
#IfDef CONFIG_FLAG
... code ...
#Endif
Try debugging that, and trying to figure out why the wrong conditional code
is being used.
While useful as a way of adding implementation-specific features, a
catch-all "comment" doesn't sound good to me.
--
Kenneth Brody
jameskuyper
I agree; I was trying to figure out what the standard actually says,
and to suggest alternative wording that would make it clearer.
However, all the committee had to do to make a diagnostic mandatory
would have been to leave out non-directives entirely; they would then
have constituted syntax errors. In defining a "non-directive", the
committee went out of their way to make it not be a syntax error; I
presume they had a reason - I'm curious what it was. Until I know that
reason, and can judge it's validity, I didn't want to suggest changing
it to a syntax error.
Willem
) Just from a usability point of view, how would making it
) implementation-defined be better than a mandatory diagnostic?
Extensibility, basically. Otherwise any compiler that recognizes
directives that are not defined in the standard would be required to emit a
diagnostic even though to them it's something they're perfectly happy with.
Keith Thompson
> Keith Thompson wrote:
> ) Just from a usability point of view, how would making it
> ) implementation-defined be better than a mandatory diagnostic?
>
> Extensibility, basically. Otherwise any compiler that recognizes
> directives that are not defined in the standard would be required to emit a
> diagnostic even though to them it's something they're perfectly happy with.
We have exactly the same situation with extensions.
If a compiler defines an extension, say, a "long long long" type, it's
still required to issue a diagnostic for any occurrence of "long long
long"; it's then free to continue compilation and implement whatever
behavior it likes. If you want to use "long long long" without being
bothered by diagnostics, just invoke the compiler in a non-conforming
mode. You can use the extension, and I can still get a diagnostic if
I type "long" more times than I intended to.
In any case, I don't think that was the intent. As the Rationale says:
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.
My best guess is that the intent was that a non-directive would never
survive all the phases of translation. I just can't figure out how
that's supposed to happen. I'm hoping my query in comp.std.c will
produce either a definitive answer or an acknowledgement that the
standard's text doesn't properly describe the intent.
Tim Rentsch
The problem is, 5.1.1.2p4 says "Preprocessing directives are
executed," but there is no statement of what behavior occurs
when a 'non-directive' is executed. There is for every other
preprocessing directive (including '# <new-line>'). It's
this absence that convinved me that an unskipped 'non-directive'
is undefined behavior.
Tim Rentsch
Right. It's deleted at the end of phase 4 (assuming that the UB
that arises from "executing" it doesn't contradict that).
> I just can't figure out how that's supposed to happen.
It gets deleted because of the last sentence of 5.1.1.2p1.4 says
it will be (oops, bad reference in a previous posting). The
question is what happens when it gets executed, and the Standard
doesn't say anything about that, which is what makes the behavior
undefined.
> I'm hoping my query in comp.std.c will
> produce either a definitive answer or an acknowledgement that the
> standard's text doesn't properly describe the intent.
It's there to make sure that every line starting with '#' is
considered a preprocessing directive, and it's undefined to
give implementations a chance to define them. It just would be
nice if that had been handled a little better and been made
a little more clear in the Standard.
Kenneth Brody
>
> Kenneth Brody wrote:
>> While useful as a way of adding implementation-specific features, a
>> catch-all "comment" doesn't sound good to me.
>
> I agree; I was trying to figure out what the standard actually says,
> and to suggest alternative wording that would make it clearer.
> However, all the committee had to do to make a diagnostic mandatory
> would have been to leave out non-directives entirely; they would then
> have constituted syntax errors. In defining a "non-directive", the
> committee went out of their way to make it not be a syntax error; I
> presume they had a reason - I'm curious what it was. Until I know that
> reason, and can judge it's validity, I didn't want to suggest changing
> it to a syntax error.
It doesn't have to be a "syntax error" to be an "error". After all, the
following isn't a "syntax error", either:
fprintf(37,"hello"+"there");
But, the lack of description as to what "non-directive" is for does leave a
bit to be desired. It could be used for implementation-defined extensions,
but it doesn't explicitly state that, nor does it state what to do with
"unknown" "non-directives". For example, 6.10.6p1 says that any #pragma
other than STDC is "implementation-defined".
--
Kenneth Brody
James Kuyper
> jameskuyper wrote:
>>
>> Kenneth Brody wrote:
> [...]
>>> While useful as a way of adding implementation-specific features, a
>>> catch-all "comment" doesn't sound good to me.
>>
>> I agree; I was trying to figure out what the standard actually says,
>> and to suggest alternative wording that would make it clearer.
>> However, all the committee had to do to make a diagnostic mandatory
>> would have been to leave out non-directives entirely; they would then
>> have constituted syntax errors. In defining a "non-directive", the
>> committee went out of their way to make it not be a syntax error; I
>> presume they had a reason - I'm curious what it was. Until I know that
>> reason, and can judge it's validity, I didn't want to suggest changing
>> it to a syntax error.
>
> It doesn't have to be a "syntax error" to be an "error". After all, the
> following isn't a "syntax error", either:
I would want a diagnostic to be mandatory; the simplest way to make that
happen is to make it a syntax error, by removing 'non-directive' from
the grammar. Of course, a constraint violation or an explicit statement
that a diagnostic is required would do just as well.
This would not prevent the development of implementation-specific
preprocessing directives. In conforming mode, a compiler could issue a
diagnostic saying "warning: non-standard feature #explain used", and
that warning could be turned off by an option that would render the
compiler non-conforming.
My point is - the committee went out of their way to put "non-directive"
into the grammar. Why? Until I know why, I don't want to suggest
removing it. Keith's inquiry on comp.std.c has received no authoritative
response yet, which is a bit disappointing.
jacob navia
>
> My point is - the committee went out of their way to put "non-directive"
> into the grammar. Why? Until I know why, I don't want to suggest
> removing it. Keith's inquiry on comp.std.c has received no authoritative
> response yet, which is a bit disappointing.
>
Well, this is just a bug.
Nobody is perfect, and committee members aren't either.
The preprocessor of lcc-win uses is a version that was written by Dennis Ritchie.
I have maintained his code for many years, and he does complain at any
directive that is not a known directive. This bug in the specs was introduced
later, and I am glad his version doesn't have it.
Keith Thompson
Assuming that the behavior of a "non-directive" is undefined,
Ritchie's preprocessor is consistent with the spec, at least with
respect to this feature.
Keith Thompson
> Keith Thompson <ks...@mib.org> writes:
[...]
>> My best guess is that the intent was that a non-directive would never
>> survive all the phases of translation.
>
> Right. It's deleted at the end of phase 4 (assuming that the UB
> that arises from "executing" it doesn't contradict that).
>
>> I just can't figure out how that's supposed to happen.
>
> It gets deleted because of the last sentence of 5.1.1.2p1.4 says
> it will be (oops, bad reference in a previous posting). The
> question is what happens when it gets executed, and the Standard
> doesn't say anything about that, which is what makes the behavior
> undefined.
Ok. The reference paragraph, which describes translation phase 4,
says
Preprocessing directives are executed, macro invocations are
expanded, and _Pragma unary operator expressions are executed.
[snip]
All preprocessing directives are then deleted.
And yes, the meaning of executing a non-directive (which is a
directive) is the sticking point. Since the standard doesn't define
the behavior, the behavior is undefined.
>> I'm hoping my query in comp.std.c will
>> produce either a definitive answer or an acknowledgement that the
>> standard's text doesn't properly describe the intent.
>
> It's there to make sure that every line starting with '#' is
> considered a preprocessing directive, and it's undefined to
> give implementations a chance to define them. It just would be
> nice if that had been handled a little better and been made
> a little more clear in the Standard.
I have a much clearer understanding of what the standard *says*
about non-directives. But I'm still waiting for a definitive
statement about the intent. (Such a statement cannot be based
only on the wording of the standard; it's about the state of mind
of the authors.)
The standard would be substantially improved by an explicit
statement that the behavior of executing a non-directive is
undefined. It would be improved even more, IMHO, by a statement
that executing a non-directive is a constraint violation. If I
misspell a keyword, the compiler complains, and in most cases
it's required to complain. The (apparent) fact that this doesn't
apply to misspelled preprocessor directives is counterintuitive.
This would still leave room for implementation-defined extensions.
(I thought about using the common extension "#warning" as an example,
but since the whole purpose of "#warning" is to trigger a diagnostic,
it's probably the worst possible example.)
Richard Bos
It is a non-directive. Since no meaning is defined for non-directives,
they have undefined behaviour. Therefore, if the implementation can show
that a non-directive will be reached, it is allowed to reject the source
code entirely.
Richard
Keith Thompson
> Tim Rentsch <t...@alumni.caltech.edu> wrote:
[...]
>> My reading is that
>>
>> #DEFINE <pp-tokens> <new-line>
>>
>> (which presumably is what was there) is legal, and should not
>> have been rejected.
>
> It is a non-directive. Since no meaning is defined for non-directives,
> they have undefined behaviour. Therefore, if the implementation can show
> that a non-directive will be reached, it is allowed to reject the source
> code entirely.
Or it an silently ignore it, which is the problem.
Eric Sosman
> [...]
> It is a non-directive. Since no meaning is defined for non-directives,
> they have undefined behaviour. Therefore, if the implementation can show
> that a non-directive will be reached, it is allowed to reject the source
> code entirely.
If you're correct that a non-directive produces undefined
behavior, I don't think "reachability" matters. Some kinds of
U.B. are unrelated to the flow of program execution. For example,
declaring an identifier with both external and internal linkage
in the same translation unit yields undefined behavior, yet the
internal-linkage declaration is necessarily outside any executable
block and is thus "unreachable" by definition.
I'm still keeping an open mind about whether an N-D produces
undefined behavior. On the larger question of what an N-D is
*for*, my mind is not only open but empty ...
Keith Thompson
Assuming the intent is to allow implementation-specific preprocessor
directives, making the behavior undefined even if it's unreachable
would make it nearly useless.
For example, suppose Foo C supports a "#include_once" directive:
#ifdef __FOO_C__
#include_once "blah.h"
#else
#include "blah.h"
#endif
The obvious intent is that the #include_once directive will be seen
only by the Foo C compiler.
I still dislike what seems to be the intent; if an implementation
doesn't support "#include_once", a diagnostic should be mandatory for
that implementation.
jameskuyper
> Richard Bos wrote:
> > [...]
> > It is a non-directive. Since no meaning is defined for non-directives,
> > they have undefined behaviour. Therefore, if the implementation can show
> > that a non-directive will be reached, it is allowed to reject the source
> > code entirely.
>
> If you're correct that a non-directive produces undefined
> behavior, I don't think "reachability" matters. Some kinds of
> U.B. are unrelated to the flow of program execution. For example,
> declaring an identifier with both external and internal linkage
> in the same translation unit yields undefined behavior, yet the
> internal-linkage declaration is necessarily outside any executable
> block and is thus "unreachable" by definition.
For a pre-processing directive "will be reached" means that it
survives conditional compilation.
Dietmar Schindler
> For a pre-processing directive "will be reached" means that it
> survives conditional compilation.
I cannot find anything in the Standard that would support the above
statement. Moreover, I cannot find anything in the Standard that would
indicate that any pre-processing directive can ever be /reached/.
James Kuyper
The standard never defines what the term "reached" means, it only uses
the term in contexts where it refers to something that happens a run
time, not compile time. It does not use the term when explaining
undefined behavior.
What it does say is that behavior is undefined "upon use of a
nonportable or erroneous program construct or of erroneous data," a
sufficiently vague statement that the Committee has had to resolve some
defect reports based upon uncertainties about what precisely constitutes
a "use"; those rulings indicate that for most kinds of undefined
behavior, "use" requires that execution of the program must be
guaranteed (absent the undefined behavior) to reach the relevant line of
code.
However, Undefined behavior associated with preprocessing necessarily
involves a "use" that occurs at compile time, not run time.
The standard does specify that if conditional compilation causes a group
of lines to be skipped, "directives are processed only through the name
that determines the directive in order to keep track of the level of
nested conditionals; the rest of the directives’ preprocessing tokens
are ignored, as are the other preprocessing tokens in the group." In
that case, the standard defines exactly what happens to such lines, so
it is not possible to claim undefined behavior "by the omission of any
explicit definition of behavior".
Tim Rentsch
Yes, as I already explained two days earlier in my followup
posting.
Tim Rentsch
> Richard Bos wrote:
>> [...]
>> It is a non-directive. Since no meaning is defined for non-directives,
>> they have undefined behaviour. Therefore, if the implementation can show
>> that a non-directive will be reached, it is allowed to reject the source
>> code entirely.
>[snip]
> I'm still keeping an open mind about whether an N-D produces
> undefined behavior. [snip]
Do you mean open as to whether non-directives are undefined
behavior, or whether non-directives were meant to be undefined
behavior? The case for non-directives being undefined behavior
seems pretty cut-and-dried, since no definition is given for
what happens when they are "executed".
Tim Rentsch
>>[snip]
>
> Assuming the intent is to allow implementation-specific preprocessor
> directives, making the behavior undefined even if it's unreachable
> would make it nearly useless.
>
> For example, suppose Foo C supports a "#include_once" directive:
>
> #ifdef __FOO_C__
> #include_once "blah.h"
> #else
> #include "blah.h"
> #endif
>
> The obvious intent is that the #include_once directive will be seen
> only by the Foo C compiler.
The behavior in such cases is covered, just as it is for #include,
etc, in 6.10.1p6 -- defined to skip the directive if __FOO_C__ has
not been #define'd.
Tim Rentsch
You mean you don't consider my speculations and guesses to
have as much value as comments from someone who actually
knows what's going on? I'm crushed. :)
> The standard would be substantially improved by an explicit
> statement that the behavior of executing a non-directive is
> undefined. It would be improved even more, IMHO, by a statement
> that executing a non-directive is a constraint violation. If I
> misspell a keyword, the compiler complains, and in most cases
> it's required to complain. The (apparent) fact that this doesn't
> apply to misspelled preprocessor directives is counterintuitive.
> This would still leave room for implementation-defined extensions.
I would second a motion to propose such a change as
part of C1X. Possibly I would change my mind about
whether the change should be adopted after hearing
the discussion, but I'd like to hear the discussion
first.
Tim Rentsch
> Kenneth Brody wrote:
>> jameskuyper wrote:
>>>
>>> Kenneth Brody wrote:
>> [...]
>>>> While useful as a way of adding implementation-specific features, a
>>>> catch-all "comment" doesn't sound good to me.
>>>
>>> I agree; I was trying to figure out what the standard actually says,
>>> and to suggest alternative wording that would make it clearer.
>>> However, all the committee had to do to make a diagnostic mandatory
>>> would have been to leave out non-directives entirely; they would then
>>> have constituted syntax errors. In defining a "non-directive", the
>>> committee went out of their way to make it not be a syntax error; I
>>> presume they had a reason - I'm curious what it was. Until I know that
>>> reason, and can judge it's validity, I didn't want to suggest changing
>>> it to a syntax error.
>>
>> It doesn't have to be a "syntax error" to be an "error". After all,
>> the following isn't a "syntax error", either:
>
> I would want a diagnostic to be mandatory; the simplest way to make
> that happen is to make it a syntax error, by removing 'non-directive'
> from the grammar. [snip]
The /simplest/ way would be to add a statement saying that a
diagnostic is mandatory. Changing the syntax would mean
making a number of other changes in the subsequent text
of 6.10 and 6.10.x
> My point is - the committee went out of their way to put
> "non-directive" into the grammar. Why? [snip]
It seems clear that the point is to make non-directives be considered
similarly to other preprocessing directives, eg, should be deleted at
the end of phase 4, should be illegal in multi-line macro calls, etc.
Just because their behavior isn't defined doesn't mean that there is
no value in putting in clues of this sort. The Standard is read by
humans, not computers.
Keith Thompson
As James said, the standard doesn't use the word "reached" in this context,
but you can see the idea in the description of #error (C99 4p4):
The implementation shall not successfully translate a
preprocessing translation unit containing a #error preprocessing
directive unless it is part of a group skipped by conditional
inclusion.
Keith Thompson
> James Kuyper <james...@verizon.net> writes:
[...]
>> I would want a diagnostic to be mandatory; the simplest way to make
>> that happen is to make it a syntax error, by removing 'non-directive'
>> from the grammar. [snip]
>
> The /simplest/ way would be to add a statement saying that a
> diagnostic is mandatory. Changing the syntax would mean
> making a number of other changes in the subsequent text
> of 6.10 and 6.10.x
The simplest way would be to make it a constraint violation; the
requirement for a diagnostic would fall out of that.
Explicitly stating that a constraint is required would add a fourth
special case to the existing things that require diagnostics: syntax
errors, constraint violations, and #error.
Richard Bos
It is obvious from the requirements for the #error directive (spec. the
one in section 4), even though the phrasing used may be different. (Note
that I did not write "reached upon execution", and in fact meant
"reached during translation").
Richard
Tim Rentsch
> Tim Rentsch <t...@alumni.caltech.edu> writes:
>> James Kuyper <james...@verizon.net> writes:
> [...]
>>> I would want a diagnostic to be mandatory; the simplest way to make
>>> that happen is to make it a syntax error, by removing 'non-directive'
>>> from the grammar. [snip]
>>
>> The /simplest/ way would be to add a statement saying that a
>> diagnostic is mandatory. Changing the syntax would mean
>> making a number of other changes in the subsequent text
>> of 6.10 and 6.10.x
>
> The simplest way would be to make it a constraint violation;
I'm not sure I agree; more below.
> the requirement for a diagnostic would fall out of that.
>
> Explicitly stating that a constraint is required would add a fourth
> special case to the existing things that require diagnostics: syntax
> errors, constraint violations, and #error.
The word 'constraint', especially as defined in 3.8p1, doesn't
describe the situation with non-directive very well. Making
executing a non-directive be a constraint violation would require
issuing a diagnostic, but this rule isn't so much a "restriction" as
a "prohibition". It seems likely that this same reasoning (or
similar reasoning) is why '#error' is defined as requiring a
diagnostic, rather than being identified as under a Constraints
section.
I understand the desire not to add more cases (be they special or
otherwise) to the set of things that require a diagnostic. At the
same time, it's not a good idea to lump something in with an existing
category, just for the sake of convenience, if it doesn't really fit
in that category. In my opinion the situation with 'non-directive'
is different enough from other conditions identified as Constraints
to think that this term may not be appropriate here. To say this
another way, I think the situation with 'non-directive' is more like
'#error' than it is like a constraint violation; if the Standard is
going to be consistent in how it uses terminology, then either both
'#error' and 'non-directive' should be constraint violations or
neither should be [assuming that we want 'non-directive' to require a
diagnostic, which I'm taking as a given for the sake of discussion].
I think I understand the reasoning that went into the decision on how
to handle '#error'; since the same reasoning seems to apply to
'non-directive', unless there's an argument I haven't thought of yet,
then just giving an explicit statement that a diagnostic must be
issued seems like the better course.
Returning to the larger issue, maybe the best way to clear up what's
going on with 'non-directive' would be to write a 'Recommended
practice' paragraph or two saying that encountering a 'non-directive'
should produce a diagnostic message, perhaps depending on a compiler
option that allows some implementation-specific preprocessing
directives. There is some precedent for such a provision, namely,
6.4.4.2p6 (and for convenience here it is):
The implementation should produce a diagnostic message if a
hexadecimal constant cannot be represented exactly in its
evaluation format; the implementation should then proceed
with the translation of the program.
Of course the specific wording for 'non-directive' would be
very different, but the general approach might be a good
idea here considering the current state of affairs.
Keith Thompson
I disagree. I think the main reason #error is handled separately is
that, unlike a constraint error, it requires the compilation to fail.
Another reason, I suppose, is that #error is something you'd write
intentionally.
I still think that a "non-directive" should be treated as a
constraint violation. Or the grammar production for "non-directive"
could just be dropped, making it a syntax error. The result would
be the same either way.
There are two reasons a non-directive might appear in a program:
1. It's an implementation-specific extension. Consider a core
language extension like "short float". A conforming implementation
must issue a diagnostic for "short float"; it can then accept the
translation unit anyway and do what it likes with the the semantics.
And it can also provide a non-conforming mode in which it doesn't
issue the diagnostic; the conforming mode is still there to warn
you that it's not portable.
I can think of no good reason why a preprocessor extension like, say,
"#include_once", should be treated any differently.
2. It's a typo. If I accidentally type "#elsif" rather than "#elif",
the compiler IMHO should be *required* to diagnose the error.
Even if the compiler "helpfully" treats "#elsif" as a synonym for
"#elif", I want to know that my code isn't portable. (I think most
compilers already do, so requiring it wouldn't be a burden.)
[snip]
Tim Rentsch
> constraint violation. [snip elaboration]
The most important thing, and the point we're most in agreement
on, is that the Standard would be improved if the question of
how 'non-directive's are treated were addressed more explicitly
and directly. After/if there is some level of consensus for
doing something, then we can take up again the question of
just what explicit requirements are most appropriate.
Keith Thompson
>> I still think that a "non-directive" should be treated as a
>> constraint violation. [snip elaboration]
>
> The most important thing, and the point we're most in agreement
> on, is that the Standard would be improved if the question of
> how 'non-directive's are treated were addressed more explicitly
> and directly. After/if there is some level of consensus for
> doing something, then we can take up again the question of
> just what explicit requirements are most appropriate.
IMHO, there's no reason not to consider what the requirements
should be. Making the requirements more explicit and making them
"good" are two somewhat separate issues, but I have no problem
considering both issues simultaneously.
If the committee were to decide to make a change in this area, they
probably wouldn't (a) decide to make it more explicit and then (b)
wait for more feedback on what to do.
Tim Rentsch
> Tim Rentsch <t...@alumni.caltech.edu> writes:
>> Keith Thompson <ks...@mib.org> writes:
> [...]
>>> I still think that a "non-directive" should be treated as a
>>> constraint violation. [snip elaboration]
>>
>> The most important thing, and the point we're most in agreement
>> on, is that the Standard would be improved if the question of
>> how 'non-directive's are treated were addressed more explicitly
>> and directly. After/if there is some level of consensus for
>> doing something, then we can take up again the question of
>> just what explicit requirements are most appropriate.
>
> IMHO, there's no reason not to consider what the requirements
> should be. Making the requirements more explicit and making them
> "good" are two somewhat separate issues, but I have no problem
> considering both issues simultaneously.
>
> If the committee were to decide to make a change in this area, they
> probably wouldn't (a) decide to make it more explicit and then (b)
> wait for more feedback on what to do.
It seems counterproductive to argue with someone who is
basically on the same side as I am. That's really all
I was trying to say.
lawrenc...@siemens.com
>
> The preprocessor of lcc-win uses is a version that was written by Dennis Ritchie.
Are you sure about that? As far as I know, DMR never wrote a preprocessor.
The original Unix cpp was written by John Reiser.
--
Larry Jones
...That would be pretty cool, if they weren't out to kill me. -- Calvin