This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Fix ObjC @"string" machinery
On 27 Jun 2005, at 20.58, Richard Henderson wrote:
On Mon, Jun 27, 2005 at 06:46:49PM -0700, Ziemowit Laski wrote:
to refer to 'targetm.objc.next_runtime' (with c.opt mods as
necessary).
I don't like this. Primarily because I'd *prefer* to have targetm
be const. At present several ports have backend-specific reasons
why they need to modify it at runtime, but I don't want to add
reasons from the front ends.
OK; one of the reasons I backed away from lang_hooks is that they are
already const...
A better solution is to simply move flag_next_runtime to be a
generic flag, rather than a C front end flag.
That'll work, too. Where should it go -- tree.c/tree.h?
+ /* Given a STRING_CST, return a reference to an Objective-C
+ @"string" literal. If this function returns NULL, the
+ default Objective-C string construction methodology will
+ be used instead. */
+ tree (*build_string_literal) (tree);
Hooks like this should never return null. You should instead have
the default be a function pointer that constructs strings in the
default way.
Well, the default routine is in objc-act.c; we can put a stub in
stub-objc.c, but the non-C-ish front-ends will still fail to link.
Another approach is for build_string_literal to simply _be_ NULL
instead of returning NULL (by default, that is); the logic in objc-act.c
would check for non-NULL-ness before calling through the pointer.
Would that be acceptable?
--Zem
--------------------------------------------------------------
Ziemowit Laski 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group Cupertino, CA USA 95014-2083
Apple Computer, Inc. +1.408.974.6229 Fax .5477