patch to do away with caching of __CFConstantStringClassReference

jahanian fjahanian at
Mon Apr 15 13:36:45 PDT 2013

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


More information about the cfe-commits mailing list