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

Flamedoge via llvm-dev llvm-dev at lists.llvm.org
Tue Apr 11 17:09:42 PDT 2017


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>


More information about the llvm-dev mailing list