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

[Jonathan Roelofs via llvm-dev]

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