patch to do away with caching of __CFConstantStringClassReference

Jordan Rose jordan_rose at
Mon Apr 15 13:43:38 PDT 2013

Without knowing much about this code, does this apply to constant NSStrings as well?

(I'm guessing people don't do this very often anyway...)


On Apr 15, 2013, at 13:38 , jahanian <fjahanian at> wrote:

> Here is the patch.
> <diff.txt>
> On Apr 15, 2013, at 1:36 PM, jahanian <fjahanian at> wrote:
>> This is // rdar://13598026
>> We cache uses of __CFConstantStringClassReference external symbol when generating the API for
>> cfstring. This, however, causes a crash in extreme rare case where user has chosen to provide a tentative
>> definition of __CFConstantStringClassReference followed by build of a cfstring followed by delayed
>> generation of another cfstring. This sequence of events causes the 2nd access to this cached symbol to be
>> a dangling reference because in the course of completing the tentative definition, the cached __CFConstantStringClassReference
>> has been erased. I fix this by removing caching of __CFConstantStringClassReference altogether. This is because
>> all global symbols are cached in llvm’s global symbol table which is tightly managed. There is no need to have our own
>> cache of this symbol. 
>> Please review.
>> - Fariborz
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the cfe-commits mailing list