Re: Preprocessor question...

[Carlo Wood <carlo at alinoe dot com>]

On Thu, Feb 15, 2001 at 01:37:51PM -1000, Glen Nakamura wrote:
> Is the following valid code?
> 
> #include <stdio.h>
> #define OFFSET (0x1000)
> #define NUMBER (0x0E+OFFSET)
> int main()
> {
>     printf("%d\n", NUMBER);
>     return 0;
> }
> 
> I get the following error when compiling with egcs-1.1.2 or gcc-2.95.2:
> 
> test.c: In function `main':
> test.c:8: missing white space after number `0x0E'
> test.c:8: `OFFSET' undeclared (first use in this function)
> test.c:8: (Each undeclared identifier is reported only once
> test.c:8: for each function it appears in.)

"0x0E+OFFSET" as a whole is a pp-number, which is defined as:

pp-number:  digit
	    . digit
	    pp-number digit
	    pp-number nondigit
	    pp-number e sign
	    pp-number E sign
	    pp-number .

0 is a digit, x is a nondigit, "E+" is "E sign", and each
of the characters of OFFSET are nondigit-s again.

As a result, the preprocessor doesn't do macro expansion
of "OFFSET", because then the "OFFSET" must be a preprocessing-token
on its own (it could be an indentifier, provided everything
before it is the longest possible preprocessing-token, but
it isn't because both "0x0E+" and "0x0E+O" are pp-numbers).

The standard says (2.4 Preprocessing tokens), point 4:

4 [Example: The program fragment 1Ex is parsed as a preprocessing number
  token (one that is not a valid floating  or  integer  literal  token),
  even though a parse as the pair of preprocessing tokens 1 and Ex might
  produce a valid expression (for example, if Ex were a macro defined as
  +1).  Similarly, the program fragment 1E1 is parsed as a preprocessing
  number (one that is a valid floating literal token), whether or not  E
  is a macro name. ]

So (I think), this is not a bug; it is correct not to expand the macro
OFFSET in this case.

-- 
Carlo Wood <carlo@alinoe.com>