[cfe-dev] Constant CFString merge

Daniel Dunbar daniel at zuster.org
Fri Aug 15 11:59:31 PDT 2008


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.

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 think perhaps we should split the UTF-16 fix, which definitely should be done
for both, from the reorganization. 

 - Daniel


----- Original Message ----
From: Jean-Daniel Dupas <devlists at shadowlab.org>
To: cfe-dev Developers <cfe-dev at cs.uiuc.edu>
Sent: Friday, August 15, 2008 3:18:21 AM
Subject: [cfe-dev] Constant CFString merge

This is a patch that merge the two constants CFString implementation  
(the one in CodeGenModule + ASTContext and  the one in CGObjMac.
Now, the CGObjMac only call the CGM.GetAddrOfConstantCFString()  
function.

It also update the CFString structure declaration by changing the  
const char *str into a void *buffer.
This is because it will be needed later to store either const char *  
or const short * for UTF16 strings (and because the CFString  
declaration in CoreFoundatio also use void *).
I don't know if it should be done like this, or if this is better to  
let char * and then add a cast from short * to char * in UTF16 string  
generation.



More information about the cfe-dev mailing list