patch to do away with caching of __CFConstantStringClassReference

[Jordan Rose]

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...)

Jordan


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

> Here is the patch.
> 
> 		
> <diff.txt>
> 
> On Apr 15, 2013, at 1:36 PM, jahanian <fjahanian at apple.com> 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 cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130415/a6a25b3c/attachment.html>