[cfe-dev] Constant CFString merge

Jean-Daniel Dupas devlists at shadowlab.org
Fri Aug 15 13:40:01 PDT 2008

Le 15 août 08 à 20:59, Daniel Dunbar a écrit :

> One problem here is how to handle emission of constant CFStrings when
> not in Objective-C mode.
> I don't really want to always have a CGObjCRuntime object around,  
> because
> the runtime is likely to want to add data to the module which should  
> only
> happen for ObjC files, and conditionalizing this in the  
> CGObjCRuntime is
> somewhat gross.

In the patch, the obj-c runtime is not required. The implementation is  
splitted into ASTContext (for the type declaration) and CodeGen (for  
The apple objc runtime only call GetAddrOfConstantCFString(), and when  
compiling a C file, you don't have to create an objc runtime, you can  
just call GetAddrOfConstantCFString() of CodeGenModule.

> This made me think that perhaps having separate methods is not so bad.
> There is also the complexity that gcc supports several options which  
> change
> how constant strings are handled, but these options should probably  
> not
> conflict with how __builtin___CFStringMakeConstantString is  
> implemented.
> I'm not yet sure how these options interact, however.

I don't know a lot of options that change the way objc/cf strings are  
generated. I'm only aware about:


Both functions does not change the way constant strings are created,  
but define if an alternative way should be used (instead of   

If the first option (-fconstant-cfstrings ) is not defined, the CFSTR  
macro definition create function call instead of call to the builtin  

The second option:

- if -fconstant-cfstrings is specified, it override this setting, and  
constant cfstrings are generated.
- if -fconstant-cfstrings is not specified, obj string generation  
should create a constant string specific to each runtime  
(NSConstantString by default for the next runtime), so it does not use  
constant CFString generation at all.

And so, I don't see any option that change the way  
GetAddrOfConstantCFString() should behave (but maybe I miss something).

> I think perhaps we should split the UTF-16 fix, which definitely  
> should be done
> for both, from the reorganization.
> - Daniel

More information about the cfe-dev mailing list