[cfe-dev] Constant CFString merge
daniel at zuster.org
Fri Aug 15 16:58:54 PDT 2008
Okay, that makes sense. The only issue then is that the runtime doesn't
get control over what the constant string class reference is called, but since
GNU and NeXT both use the same name that doesn't seem to be an issue.
RE: The patch:
(1) In ASTContext::getCFConstantStringType there is really no need to use
a SmallVector here, even if the size is changing by one. Also some of
the comments re: the type are incorrect... and why did you change the ones
you did (the str I understand, but why unsigned -> signed or const int* -> int*)?
I think it makes more sense to change this file when someone does UTF-16
(2) The NeXT runtime should still set the section on constant cfstrings.
----- Original Message ----
From: Jean-Daniel Dupas <devlists at shadowlab.org>
To: Daniel Dunbar <daniel at zuster.org>
Cc: cfe-dev Developers <cfe-dev at cs.uiuc.edu>
Sent: Friday, August 15, 2008 1:40:01 PM
Subject: Re: [cfe-dev] Constant CFString merge
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,
> the runtime is likely to want to add data to the module which should
> 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
> how constant strings are handled, but these options should probably
> conflict with how __builtin___CFStringMakeConstantString is
> 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