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

[Flamedoge via llvm-dev]

Sorry, forgot to source where I quoted:
http://en.cppreference.com/w/c/memory/free  p.5
Kevin

On Tue, Apr 11, 2017 at 5:12 PM, Jonathan Roelofs <jonathan at codesourcery.com
> wrote:

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