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

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;  val->~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