[LLVMdev] SAFECode Source Code Released

John McCall rjmccall at apple.com
Mon Nov 16 13:42:22 PST 2009


Török Edwin wrote:
> On 2009-11-16 22:46, John Criswell wrote:
>   
>> [snip]
>>     
>>> My initial message (containing the patch) was a private reply to John.
>>>
>>> Attached the patch again, it applies with 'patch -p0'.
>>>
>>> Also try to build on x86-32, x86-64 is not quite ready yet.
>>>   
>>>       
>> Actually, I made one small change to the patch.  I kept -Werror in
>> Makefile.common.in.  It's better if we fix these warnings; -Werror
>> provides incentive for that.
>>
>> I'll consider removing it if there's a problem that's not trivially
>> fixable.
>>     
>
> That leaves us with the aliasing violations. I looked at the first, and
> I couldn't tell why gcc (4.3.4) thinks it is wrong:
> safecode/runtime/BitmapPoolAllocator/PoolAllocatorBitMask.cpp:185:
> warning: dereferencing type-punned pointer will break strict-aliasing rules
> Line 185 is: PS->addToList((PoolSlab**)&Pool->Ptr2);
>
> and Ptr2 is a field of type void*. Isn't void* compatible with anything?
>   

No.  void* is _convertible_ to an arbitrary pointer type (6.3.2.3p1):

  A pointer to void may be converted to or from a pointer to any 
incomplete or object type. A pointer to any incomplete or object type 
may be converted to a pointer to void and back again; the result shall 
compare equal to the original pointer.

But the _compatibility_ rules for pointers don't mention void* (6.7.5.1p2):

  For two pointer types to be compatible, both shall be identically 
qualified and both shall be pointers to compatible types.

Nor is there an exception carved out in 6.5p1.

Among other things, this permits null pointers to have different 
representations based on the element type, &c &c.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091116/d6e3d19a/attachment.html>


More information about the llvm-dev mailing list