This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Objective C lexer - small cleanup
- To: Stan Shebs <shebs at apple dot com>
- Subject: Re: Objective C lexer - small cleanup
- From: "Zack Weinberg" <zackw at Stanford dot EDU>
- Date: Sat, 30 Jun 2001 13:15:52 -0700
- Cc: Neil Booth <neil at daikokuya dot demon dot co dot uk>, gcc-patches at gcc dot gnu dot org
On Fri, Jun 29, 2001 at 10:35:01AM -0700, Stan Shebs wrote:
> Zack Weinberg wrote:
> >
> > On Fri, Jun 29, 2001 at 07:59:09AM +0100, Neil Booth wrote:
> > > Zack Weinberg wrote:-
> > >
> > > > Nothing stops the @ from being an acceptable leading character in an
> > > > identifier, _and_ a token in its own right if it isn't followed by
> > > > identifier characters.
> > >
> > > But how would you macro expand @foo? At present foo is expanded, but
> > > "@foo" isn't a macro.
> >
> > It's my understanding that macro expansion after @ is only wanted for
> > string constants. Stan?
>
> That's right.
I thoroughly missed Neil's point, went and implemented the thing, and
now I get it. If you write
#define STRING "whatever"
NXConstantString foo = @STRING;
and the preprocessor treats '@' as an acceptable character to begin
identifiers with, it will not macro-expand STRING.
Either you have to write all such constructions as
NXConstantString foo = @ STRING;
or the preprocessor has to be made aware of all the Objective C
@-prefix keywords, or we stick with it being okay to write
#define foo interface
@foo Foo
...
The third possibility is what we have now and with the patch I
originally submitted.
--
zw The MacsBug debugger symbol displayed as the pc location for the memory
manager's code has been changed from BowelsOfTheMemoryMgr to the more
descriptive name YourHeapIsProbablyCorrupt.
-- Apple Tech Note 2010