This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]