Re: preprocessor bug: @ + MACRO does not work in gcc-3.0

[Ovidiu Predescu <ovidiu at cup dot hp dot com>]

On Mon, 5 Mar 2001 19:04:04 +0000, Neil Booth <neil@daikokuya.demon.co.uk> wrote:

> 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.

The @ symbol is actually part of the Objective-C language, it's used
to create Objective-C constant string objects. So there is nothing to
fix in GNUstep, it is simply making use of a feature in the language.

One more thing about the @ syntax, it also allows for things like
this:

id string = @"this is "
	    @"a long "
	    @"string.";

The value of `string' is equivalent as if it was declared with:

id string = @"this is a long string.";

the compiler effectively concatenating the strings together.


Regards,
Ovidiu