[llvm-dev] Potential issue with noalias @malloc and @realloc (original) (raw)

Jonathan Roelofs via llvm-dev llvm-dev at lists.llvm.org
Tue Apr 11 17:12:48 PDT 2017

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

More information about the llvm-dev mailing list