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

Sanjoy Das via llvm-dev llvm-dev at lists.llvm.org
Tue Apr 11 18:45:23 PDT 2017

Hi Daniel,

On April 11, 2017 at 6:16:32 PM, Daniel Berlin (dberlin at dberlin.org) wrote:
> 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".

Quickly scanning the spec, it looks like it tries to differentiate
between the "lifetime" of an object (starts on construction, ends on
destruction) and the time during which the storage in which the object
resides has been acquired and not been released.

In particular, it says "If, after the lifetime of an object has ended
and **before** the storage which the object occupied is reused or
released", so I suspect that wording is there to allow:

 X* val = new X;
 new(val) X;
 val->foo(); // valid use

Also, basic.stc.dynamic.deallocation says:

If the argument given to a deallocation function in the standard
library is a pointer that is not the null pointer value (4.10), the
deallocation function shall deallocate the storage referenced by the
pointer, rendering invalid all pointers referring to any part of the
deallocated storage. Indirection through an invalid pointer value and
passing an invalid pointer value to a deallocation function have
undefined behavior. *Any other use of an invalid pointer value has
implementation-defined behavior.*

-- Sanjoy

More information about the llvm-dev mailing list