This is a follow up to this other question about memory re-use. As the original question was about a specific implementation, the answer was related to that specific implementation.
So I wonder whether, it is legal in a conformant implementation to re-use the memory of an array of a fundamental type for an array of a different type provided:
I ended with the following example code:
#include <iostream>
constexpr int Size = 10;
void *allocate_buffer() {
void * buffer = operator new(Size * sizeof(int), std::align_val_t{alignof(int)});
int *in = reinterpret_cast<int *>(buffer); // Defined behaviour because alignment is ok
for (int i=0; i<Size; i++) in[i] = i; // Defined behaviour because int is a fundamental type:
// lifetime starts when is receives a value
return buffer;
}
int main() {
void *buffer = allocate_buffer(); // Ok, defined behaviour
int *in = static_cast<int *>(buffer); // Defined behaviour since the underlying type is int *
for(int i=0; i<Size; i++) {
std::cout << in[i] << " ";
}
std::cout << std::endl;
static_assert(sizeof(int) == sizeof(float), "Non matching type sizes");
static_assert(alignof(int) == alignof(float), "Non matching alignments");
float *out = static_cast<float *>(buffer); // (question here) Declares a dynamic float array starting at buffer
// std::cout << out[0]; // UB! object at &out[0] is an int and not a float
for(int i=0; i<Size; i++) {
out[i] = static_cast<float>(in[i]) / 2; // Defined behaviour, after execution buffer will contain floats
// because float is a fundamental type and memory is re-used.
}
// std::cout << in[0]; // UB! lifetime has ended because memory has been reused
for(int i=0; i<Size; i++) {
std::cout << out[i] << " "; // Defined behaviour since the actual object type is float *
}
std::cout << std::endl;
return 0;
}
I have added comments explaining why I think that this code should have defined behaviour. And IMHO everything is fine and AFAIK standard conformant, but I was not able to find whether the line marked question here is or not valid.
Float objects do re-use memory from int objects, so life time of the ints end when life time of the floats start, so the stric-aliasing rule should not be a problem. Array was dynamically allocated so objects (int and floats) are in fact all created in a void type array returned by operator new
. So I think that everything should be ok.
But as it allows for low level object replacement which is normally frowned upon in modern C++ I must acknowledge I have a doubt...
So the question is: does above code invokes UB and if yes where and why?
Disclaimer: I would advise against this code in a portable code base, and this is really a language lawyer question.
int *in = reinterpret_cast<int *>(buffer); // Defined behaviour because alignment is ok
Correct. But probably not in the sense you'd expect. [expr.static.cast]
A prvalue of type “pointer to
cv1 void
” can be converted to a prvalue of type “pointer tocv2 T
”, whereT
is an object type andcv2
is the same cv-qualification as, or greater cv-qualification than,cv1
. If the original pointer value represents the addressA
of a byte in memory andA
does not satisfy the alignment requirement ofT
, then the resulting pointer value is unspecified. Otherwise, if the original pointer value points to an objecta
, and there is an objectb
of typeT
(ignoring cv-qualification) that is pointer-interconvertible witha
, the result is a pointer tob
. Otherwise, the pointer value is unchanged by the conversion.
There is no int
nor any pointer-interconvertible object at buffer
, therefore the pointer value is unchanged. in
is a pointer of type int*
that points to a region of raw memory.
for (int i=0; i<Size; i++) in[i] = i; // Defined behaviour because int is a fundamental type: // lifetime starts when is receives a value
Is incorrect. [intro.object]
An object is created by a definition, by a new-expression, when implicitly changing the active member of a union, or when a temporary object is created.
Noticeably absent is assignment. No int
is created. In fact, by elimination, in
is an invalid pointer, and dereferencing it is UB.
The later float*
all also follows as UB.
Even in absence of all the aforementioned UB by proper use of new (pointer) Type{i};
to create objects, there is no array object in existence. The (unrelated) objects just happens to be side by side in memory. This means pointer arithmetic with the resulting pointer is also UB. [expr.add]
When an expression that has integral type is added to or subtracted from a pointer, the result has the type of the pointer operand. If the expression
P
points to elementx[i]
of an array objectx
withn
elements, the expressionsP + J
andJ + P
(where J has the value j) point to the (possibly-hypothetical) elementx[i+j] if 0 ≤ i+j ≤ n;
otherwise, the behavior is undefined. Likewise, the expressionP - J
points to the (possibly-hypothetical) elementx[i−j] if 0 ≤ i−j ≤ n;
otherwise, the behavior is undefined.
Where hypothetical element refers to the one past-the-end (hypothetical) element. Note that a pointer to a one past-the-end element that happens to be at the same address location as another object doesn't point to that other object.