#elsif

#elsif

[Philippe De Muyter]

The following program compiles without a warning with gcc -W -Wall,
but does not do what the programmer expected.

With the native cc, I get :

	**Error: /tmp/elsif.c: 8: undefined control

-----------------------------------------------------------------------
#include        "stdio.h"
#define B

int main()
        {
#if defined(A)
        printf("A defined\n");
#elsif  defined(B)
        printf("B undefined\n");
#else   /* nor A nor B */
        printf("nor A nor B defined\n");
#endif
	return 0;
        }

Re: #elsif

[Paul Eggert]

   Date: Tue, 7 Apr 1998 12:08:20 +0200 (MET DST)
   From: "Philippe De Muyter" <phdm@macqel.be>

   #if defined(A)
	   printf("A defined\n");
   #elsif  defined(B)
	   printf("B undefined\n");
   #else   /* nor A nor B */
	   printf("nor A nor B defined\n");
   #endif

As I read the C standard, if A is not defined, then GCC is required to
accept that program fragment, though I admit the standard's wording is
not entirely clear.

It might be useful for cpp to warn about skipped, unknown directives
if -W or -Wall is specified.

Re: #elsif

[Joern Rennecke]

>    Date: Tue, 7 Apr 1998 12:08:20 +0200 (MET DST)
>    From: "Philippe De Muyter" <phdm@macqel.be>
> 
>    #if defined(A)
> 	   printf("A defined\n");
>    #elsif  defined(B)
> 	   printf("B undefined\n");
>    #else   /* nor A nor B */
> 	   printf("nor A nor B defined\n");
>    #endif
> 
> As I read the C standard, if A is not defined, then GCC is required to
> accept that program fragment, though I admit the standard's wording is
> not entirely clear.
> 
> It might be useful for cpp to warn about skipped, unknown directives
> if -W or -Wall is specified.

IIRC the standard allows any number of warnings, no matter how bogus they
are.  So why not always warn about #elsif - it seems an obvious enough
typo to warn about even if we don't want to warn about unknown directives
in general.

Re: #elsif

[Gavin Romig-Koch]

Paul Eggert writes:
 >    Date: Tue, 7 Apr 1998 12:08:20 +0200 (MET DST)
 >    From: "Philippe De Muyter" <phdm@macqel.be>
 > 
 >    #if defined(A)
 > 	   printf("A defined\n");
 >    #elsif  defined(B)
 > 	   printf("B undefined\n");
 >    #else   /* nor A nor B */
 > 	   printf("nor A nor B defined\n");
 >    #endif
 > 
 > As I read the C standard, if A is not defined, then GCC is required to
 > accept that program fragment, though I admit the standard's wording is
 > not entirely clear.

I disagree.  While I agree that the standard could be clearer
about this, as I read it, a diagnostic must be issued for the
"elsif".

The syntax of preprocessing directives are clearly spelled out,
and "#elsif" does not fit.  The standard requires a diagnostic
if there is a syntax violation.

There is a passage in 3.8.1, in the context of explaining what
gets skipped by a false directive, "directives are processed
only through the name that determines the directive...".  In
this case the name is "elsif" which does not fit syntacticly.

If you read it differently Paul, show us what you see.

                                        -gavin...

Re: #elsif

[Paul Eggert]

   Date: Wed, 8 Apr 1998 10:16:11 -0400 (EDT)
   From: Gavin Romig-Koch <gavin@cygnus.com>

   The syntax of preprocessing directives are clearly spelled out,

Yes; here's the definition in the standard.

	A preprocessing directive consists of a sequence of
	preprocessing tokens that begins with a `#' preprocessing
	token that is either the first character in the source file
	(optionally after white space containing no new-line
	characters) or that follows white space containing at least
	one new-line character, and is ended by the next new-line
	character.

Draft C9x changes this wording slightly, but the change doesn't matter
for our purposes.

   and "#elsif" does not fit.

I don't see why not.  `#elsif' is a sequence of preprocessing tokens,
all alone in a line; this fits the definition quoted above.


   From: Joern Rennecke <amylaar@cygnus.co.uk<>
   Date: Wed, 8 Apr 1998 15:08:47 +0100 (BST)

   wthe standard allows any number of warnings, no matter how bogus
   they are.  So why not always warn about #elsif

I assume that you do not want to make a special case for `elsif' only.
(That would be odd; it wouldn't catch other misspellings like `elseif'.)
But if we report _all_ misspelled directives, then we run afoul of the
examples that caused RMS to change cccp.c to behave the way it does
today.

I wouldn't mind adding the checking to -W (or perhaps to -Wundef); but
I don't think it should be on by default.

Re: #elsif

[Philippe De Muyter]

> I assume that you do not want to make a special case for `elsif' only.
> (That would be odd; it wouldn't catch other misspellings like `elseif'.)
> But if we report _all_ misspelled directives, then we run afoul of the
> examples that caused RMS to change cccp.c to behave the way it does
> today.
> 
> I wouldn't mind adding the checking to -W (or perhaps to -Wundef); but
> I don't think it should be on by default.
> 
Could you rather warn for every unrecognized directive, even without -W or
-Wall, but have a list of directives accepted by other compilers for which
you would not complain ?

Re: #elsif

[Paul Eggert]

   Date: Thu, 9 Apr 1998 00:26:05 +0200 (MET DST)
   Cc: gavin@cygnus.com, gcc2@cygnus.com, egcs@cygnus.com

   Could you ... have a list of directives accepted by other compilers
   for which you would not complain ?

I'd rather not do that; it would be too much hassle to maintain.

I just thought of one other useful wrinkle: suppress the warning if
the unknown directive is in a system include file.

Re: #elsif

[Joe Buck]

> I just thought of one other useful wrinkle: suppress the warning if
> the unknown directive is in a system include file.

Only if that feature doesn't tempt us to put sloppy code into libstdc++
headers.

Re: #elsif

[Nick Ing-Simmons]

Philippe De Muyter <phdm@macqel.be> writes:
>> I assume that you do not want to make a special case for `elsif' only.
>> (That would be odd; it wouldn't catch other misspellings like `elseif'.)
>> But if we report _all_ misspelled directives, then we run afoul of the
>> examples that caused RMS to change cccp.c to behave the way it does
>> today.
>> 
>> I wouldn't mind adding the checking to -W (or perhaps to -Wundef); but
>> I don't think it should be on by default.
>> 
>Could you rather warn for every unrecognized directive, even without -W or
>-Wall, but have a list of directives accepted by other compilers for which
>you would not complain ?

What if #elsif is supported by another compiler? 

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: #elsif

[Gavin Romig-Koch]

Paul Eggert writes:
 >    Date: Wed, 8 Apr 1998 10:16:11 -0400 (EDT)
 >    From: Gavin Romig-Koch <gavin@cygnus.com>
 > 
 >    The syntax of preprocessing directives are clearly spelled out,
 > 
 > Yes; here's the definition in the standard.
 > 
 > 	A preprocessing directive consists of a sequence of
 > 	preprocessing tokens that begins with a `#' preprocessing
 > 	token that is either the first character in the source file
 > 	(optionally after white space containing no new-line
 > 	characters) or that follows white space containing at least
 > 	one new-line character, and is ended by the next new-line
 > 	character.
 > 
 > Draft C9x changes this wording slightly, but the change doesn't matter
 > for our purposes.
 > 
 >    and "#elsif" does not fit.
 > 
 > I don't see why not.  `#elsif' is a sequence of preprocessing tokens,
 > all alone in a line; this fits the definition quoted above.

Yes, I see.  I don't like it :-), but I agree.  

Since the directive is ifdef'ed out, it can just be a sequence of
pp-tokens that are ignored.

So yes, a warning is appropriate in this case. 

                                             -gavin

Re: #elsif

[Joern Rennecke]

> I assume that you do not want to make a special case for `elsif' only.
> (That would be odd; it wouldn't catch other misspellings like `elseif'.)

Yes, if we warn for elsif, we should have a like warning for elseif.
Both are misspellings of elif that mirror a programming language and
might thus be mistaken for the real thing.  They are special because they
are supposedly meant to end the commenting out.  If there were likely
misspellings of #endif that could be mistaken for the real thing doe to
the similarity with another language (hmmm... maybe #fi would qualify?),
that these should also be warned about.

The warning for such a specific test should not just be something
vanilla like unrecognized #-directive, since that could make people
think we warned about all unrecognized directives.
It should somehow point out the assumed error.

Re: #elsif

[Ulrich Drepper]

eggert@twinsun.com (Paul Eggert) writes:

> As I read the C standard, if A is not defined, then GCC is required to
> accept that program fragment, though I admit the standard's wording is
> not entirely clear.

The wording may not, but section 6.8 is very clear.  `control line'
mentions only a fixed amount of possibilities which start with # and
which are handled separately.  All other input is handled as
preprocessing-token and is in case of a not fulfilled #if condition to
be ignored.  The current behaviour is therefore ok.

This also means that #elsif never must be an error but warnings can be
issued if one wants.  But since some compiler manufacturers invent new
# directives it is questionable.  (Of course # directives shouldn't be
introduced but this is something different).

I therefore vote against changing the current behaviour or at least
make the warning not available in -Wall.

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: #elsif

[SXTHREE]

I do not think elsif is a standard preprocessor directive.
C++ standards say the correct directive is "elif".
(Or maybe I missed some versions of the standard).
Seems strange gcc accepts this construct without warnings.

FM