[llvm-dev] Potential issue with noalias @malloc and @realloc

[Daniel Berlin via llvm-dev]

The corresponding line does not exist, and it is in fact, wrong :)

C11 says nothing like that.
C++14 says:
"The lifetime of an object of type T begins when:
— storage with the proper alignment and size for type T is obtained, and —
if the object has non-trivial initialization, its initialization is
complete.
The lifetime of an object of type T ends when:
— if T is a class type with a non-trivial destructor (12.4), the destructor
call starts, or
— the storage which the object occupies is reused or released."

it also says:
"If, after the lifetime of an object has ended and before the storage which
the object occupied is reused or released, a new object is created at the
storage location which the original object occupied, a pointer that pointed
to the original object, a reference that referred to the original object,
or the name of the original object will automatically refer to the new
object and, once the lifetime of the new object has started, can be used to
manipulate the new object, if:
...
a bunch of conditions".

Which makes it even worse because they become aliasing again.



On Tue, Apr 11, 2017 at 5:09 PM, Flamedoge via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I don't know when this was added on cppreference but
>
> > The behavior is undefined if after free() returns, an access is made
> through the pointer ptr (unless another allocation function happened to
> result in a pointer value equal to ptr)
>
> This seems to suggest that there is no UB... However, I couldn't find the
> corresponding line or relevant part on latest C std,
> http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf
>
> Regards,
> Kevin
>
> On Tue, Apr 11, 2017 at 4:27 PM, Sanjoy Das <sanjoy at playingwithpointers.
> com> wrote:
>
>> Hi Kevin,
>>
>> On April 11, 2017 at 4:14:14 PM, Flamedoge (code.kchoi at gmail.com) wrote:
>> > So only "non-freed" malloc pointers are No-Alias which makes it
>> > flow-sensitive. There is no reason why malloc couldn't return previously
>> > freed location.
>>
>> Yes.
>>
>> Talking to Nick Lewycky on IRC, I figured out a shorter way of saying
>> what I wanted to say.  We know that programs like this are UB in C:
>>
>> p0 = malloc();
>> free(p0);
>> p1 = malloc();
>> if (p0 == p1) {
>>   int v = *p0; // Semantically free'ed but bitwise equal to an allocated
>> value
>> }
>>
>> and we relied on them having UB when marking malloc's return value as
>> noalias.
>>
>> However, we can end up in cases like the above by applying
>> loop-unswitch + GVN to well defined C programs.
>>
>> -- Sanjoy
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170411/e2e8728c/attachment-0001.html>