llvm dev - Apr 2017 - Potential issue with noalias @malloc and @realloc

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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170411/8f913187/attachment.html>

On 4/11/17 6:09 PM, Flamedoge via llvm-dev 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
C99 says that p0 has indeterminate value after the free.


Jon
>
> Regards,
> Kevin
>
> On Tue, Apr 11, 2017 at 4:27 PM, Sanjoy Das
> <sanjoy at playingwithpointers.com <mailto:sanjoy at
playingwithpointers.com>>
> wrote:
>
>     Hi Kevin,
>
>     On April 11, 2017 at 4:14:14 PM, Flamedoge (code.kchoi at gmail.com
>     <mailto: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
>
-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded / Siemens

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>