Re: preprocessor/9203: preprocessor

Re: preprocessor/9203: preprocessor

[neil]

Synopsis: preprocessor

State-Changed-From-To: open->closed
State-Changed-By: neil
State-Changed-When: Mon Jan  6 15:12:47 2003
State-Changed-Why:
    Not a bug.  If an identifier in #if is not an expandable macro, it is replaced by 0 as required by ISO C.
    You can get a warning for this latter case (when the identifier is not a macro) with -Wundef.
    
    All this is documented in the manual.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9203

preprocessor/9203: preprocessor

[michael]

>Number:         9203
>Category:       preprocessor
>Synopsis:       preprocessor
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 06 14:36:00 PST 2003
>Closed-Date:
>Last-Modified:
>Originator:     Michael Haardt
>Release:        3.2
>Organization:
>Environment:
System: Linux palantir 2.4.20-rc1 #8 Wed Nov 6 23:26:07 CET 2002 i686 unknown
Architecture: i686

	
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../gcc-3.2/configure --prefix=/usr
>Description:

The preprocessor allows to compare numbers with identifiers.  I am not
sure if it's a bug or required by the standard, but even if it is legal,
a warning just would have saved me some time.  According to the ANSI C
grammar (K&R, 2nd edition), the syntax allows the comparison.  I can't
find a reference concerning semantics.
	
>How-To-Repeat:

michael@elrond; cat a.c
#if 123<ABC
number less than identifier
#else
number greater than identifier
#endif
michael@elrond; gcc -E -Wall -ansi -pedantic a.c
# 1 "a.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "a.c"



number greater than identifier


>Fix:

Even if it is legal, which I doubt but can not tell, -Wall should
issue a warning.  Otherwise of course an error would be nice.

The above happened in a comparison of #define constants, of which
one was spelled wrong, so it was not substituted.  That can easily
happen and I would appreciate gcc telling me so.

Michael
>Release-Note:
>Audit-Trail:
>Unformatted: