@@ -3327,6 +3327,19 @@ behavior is undefined:
33273327- the size of all allocated objects must be non-negative and not exceed the
33283328 largest signed integer that fits into the index type.
33293329
3330+ Allocated objects that are created with operations recognized by LLVM (such as
3331+ :ref:`alloca <i_alloca>`, heap allocation functions marked as such, and global
3332+ variables) may *not* change their size. (``realloc``-style operations do not
3333+ change the size of an existing allocated object; instead, they create a new
3334+ allocated object. Even if the object is at the same location as the old one, old
3335+ pointers cannot be used to access this new object.) However, allocated objects
3336+ can also be created by means not recognized by LLVM, e.g. by directly calling
3337+ ``mmap``. Those allocated objects are allowed to grow to the right (i.e.,
3338+ keeping the same base address, but increasing their size) while maintaining the
3339+ validity of existing pointers, as long as they always satisfy the properties
3340+ described above. Currently, allocated objects are not permitted to grow to the
3341+ left or to shrink, nor can they have holes.
3342+
33303343.. _objectlifetime:
33313344
33323345Object Lifetime
@@ -11870,6 +11883,9 @@ if the ``getelementptr`` has any non-zero indices, the following rules apply:
1187011883 :ref:`based <pointeraliasing>` on. This means that it points into that
1187111884 allocated object, or to its end. Note that the object does not have to be
1187211885 live anymore; being in-bounds of a deallocated object is sufficient.
11886+ If the allocated object can grow, then the relevant size for being *in
11887+ bounds* is the maximal size the object could have while satisfying the
11888+ allocated object rules, not its current size.
1187311889 * During the successive addition of offsets to the address, the resulting
1187411890 pointer must remain *in bounds* of the allocated object at each step.
1187511891
0 commit comments