Re: String constant concatenation in c-lex.c

[Stan Shebs <shebs at apple dot com>]

Zack Weinberg wrote:
> 
> On Thu, Jun 21, 2001 at 03:35:49PM -0700, Stan Shebs wrote:
> >
> > Hmmm.  @"" is basically an object constructor, while I think of
> > string concatenation as lower-level, so it doesn't seem as sensible
> > to mimic L prefix behavior.  It feels almost like having a function
> > call in the middle of a pile of constant args.  I wouldn't even mind
> > only allowing the middle case, but there would almost certainly be a
> > compat problem if the first case were disallowed.
> >
> > Since there's no ObjC committee to debate this endlessly :-), how
> > about we make our users happy and go with the L prefix rule anyway,
> > so an @ anywhere in a group of concatenated strings will cause the
> > result to be an @-string.  If that's going to be extra work to
> > implement, I'll be glad to help.
> 
> I tried to implement this yesterday and ran afoul of another rule:
> 
> #define STRING "whatever"
> ...
> NXConstantString str = @STRING;
> 
> is valid.  This forces the initial @ to be a separate token from the
> string constant, and that means everything I've tried causes there to
> be a communications mess between cpplib, c-lex.c, and the parser.

Yeah, @STRING is commonly used, since it's a way to share string
content between C/C++ and ObjC worlds.

> We also run into a can of worms with e.g. @"foo" L"bar"...
> NXConstantString doesn't handle wide string literals, right?

Yes.

> I'm tempted to push the entire mess off and leave concatenation of
> @-strings in the parser.  That will mean the syntax of a string
> literal object is
> 
>    '@' STRING+ ('@' STRING+) *
> 
> since @ "foo" "bar" "baz" will be converted to @ "foobarbaz" by the
> lexer.  Can you live with this at least transitionally?

I've asked internally about some of the issues, and got a mess of
replies to organize and present.  Perhaps the most important point
is that @"foo" @"bar" is indeed used in real code, so it will have
to work sooner or later, but it doesn't need to work this week or
next.

Stan