This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: preprocessor bug: @ + MACRO does not work in gcc-3.0
- To: Nicola Pero <n dot pero at mi dot flashnet dot it>
- Subject: Re: preprocessor bug: @ + MACRO does not work in gcc-3.0
- From: Neil Booth <neil at daikokuya dot demon dot co dot uk>
- Date: Mon, 5 Mar 2001 19:04:04 +0000
- Cc: gcc-bugs at gcc dot gnu dot org, Zack Weinberg <zackw at Stanford dot EDU>
- References: <Pine.LNX.3.96.1010305201636.28241A-100000@leonardo>
Nicola Pero wrote:-
> static NSString *gnustep_target_dir =
> #ifdef GNUSTEP_TARGET_DIR
> @GNUSTEP_TARGET_DIR;
> #else
> nil;
> #endif
>
> then, we compile with the compiler flag -DGNUSTEP_TARGET_DIR=\"ix86/linux-gnu\"
>
> With gcc-2.95.2, the preprocessor replaces the macro, generating
>
> static NSString *gnustep_target_dir = @"ix86/linux-gnu";
>
> which is then compiled by the Objective-C compiler into Objective-C - at
> that stage, @"ix86/linux-gnu" is turned into an Objective-C constant
> string and all works.
>
> With gcc-3.0, I get the following error -
>
> NSBundle.m:88: invalid identifier `@GNUSTEP_TARGET_DIR'
> NSBundle.m:88: `@GNUSTEP_TARGET_DIR' undeclared here (not in a function)
>
> and compilation aborts.
Right. cpplib treats (with -objc) @ + identifier as a single
identifier token; remember that previously the front end would do its
own tokenisation, but now cpplib is the sole tokeniser. Thus there is
no macro to replace, since the token does not match the macro name.
I see several solutions to this:
1) We leave it as it is, and "fix" GNUstep
2) We make CPP aware of the extra objective C keywords, and only have it
slurp the @ into the token if it discovers one of those keywords
3) We stop CPP from recognising these as tokens (and therefore prohibit
pasting them from an "@" and an identifier too) and have the objective
C front end read the next token when it is returned a token of "@".
4) Something else I've not thought of.
I think 2) is a bad solution, for a couple of reasons. One, it treats
ObjC keywords as somehow more special than C keywords, and, worse, it
requires the CPP lexer to jump through hoops with lookahead to know
whether it has an ObjC single token or 2 separate tokens.
I think 3) is not great either, but doable.
I tend to think 1) is the right answer, and that current tokenisation is
the ideal form. You can probably achieve the effect you want with macros,
in a way that also works with older versions of GCC, by pasting expanded
macros (through an extra level of indirection) with an "@" token.
Zack, what do you think?
Neil.