[cfe-commits] [PATCH] Fixed SrcMgr::FileInfo pointer magic issue in getContentCache()

Riku Palomäki riku at multitouch.fi
Wed Nov 14 11:25:33 PST 2012


On Wed, Nov 14, 2012 at 9:12 PM, Matthieu Monrocq
<matthieu.monrocq at gmail.com> wrote:
>
>
> On Tue, Nov 13, 2012 at 9:47 AM, Riku Palomäki <riku at multitouch.fi> wrote:
>>
>> Hi,
>>
>> uintptr_t SrcMgr::FileInfo::Data is used to store both a pointer value
>> and some additional flags. getContentCache-function tries to get only
>> the raw pointer value from Data, but fails to do so since it uses
>> wrong size int. At least on Windows 8 with 64-bit Visual Studio 2012
>> this function always returns corrupted pointers.
>>
>> On some platforms unsigned long long would be actually too large for
>> this use. If this triggers a warning on gcc, maybe it should be
>> written like ~uintptr_t(7UL).
>>
>> Btw, why on earth would you like to store pointers and additional
>> flags to the same variable, ran out of bits?
>>
>> --
>> Riku Palomäki
>> MultiTouch
>>
>
> The LLVM and Clang compilers are highly optimized for speed and low-memory
> consumption, so classes that tend to be instantiated "en masse" often
> contain either bit fields or pack bits into the pointers.
>
> I would suggest using ~uintptr_t, just to be on the safe side, however I am
> unsure about the suffix of the literal in this case. I believe no suffix at
> all would be safe given the cast.
>
> -- Matthieu

I used ULL suffix in the patch, since similar optimization in
VTableComponent::getPointer uses that. Also grepping with ~[0-9]*ULL
from the llvm sources shows lots of cases that would break if
sizeof(0ULL) < sizeof(uint64_t).

-- 
Riku




More information about the cfe-commits mailing list