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:
- both types are fundamental type and as such have trivial dtor and default ctor
- both types have same size and alignment requirement
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 to cv2 T”, where T is an object type and cv2 is the same cv-qualification as, or greater cv-qualification than, cv1. If the original pointer value represents the address A of a byte in memory and A does not satisfy the alignment requirement of T, then the resulting pointer value is unspecified. Otherwise, if the original pointer value points to an object a, and there is an object b of type T (ignoring cv-qualification) that is pointer-interconvertible with a, the result is a pointer to b. 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 element x[i] of an array object x with n elements, the expressions P + J and J + P (where J has the value j) point to the (possibly-hypothetical) element x[i+j] if 0 ≤ i+j ≤ n; otherwise, the behavior is undefined. Likewise, the expression P - J points to the (possibly-hypothetical) element x[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.
Passer By's answer covers why the example program has undefined behaviour. I'll attempt to answer how to reuse storage without UB with minimal UB (reuse of storage for arrays is technically impossible in standard C++ given the current wording of the standard, so to achieve reuse, the programmer has to rely on the implementation to "do the right thing").
Converting a pointer does not automatically manifest objects into being. You have to first construct the float objects. This starts their lifetime and ends the lifetime of the int objects (for non-trivial objects, destructor would need to be called first):
for(int i=0; i<Size; i++)
new(in + i) float;
You can use the pointer returned by placement new (which is discarded in my example) directly to use the freshly constructed float objects, or you can std::launder the buffer pointer:
float *out = std::launder(reinterpret_cast<float*>(buffer));
However, it is much more typical to reuse the storage of type unsigned char (or std::byte) rather than storage of int objects.
I have just popped in because it felt to me that there is at least one unanswered question, that was not spoken out loud, apologies if that is not true. I think that the guys brilliantly answered the main question of this problem: where and why it is undefined behavior; user2079303 gave few ideas how to fix it. I will try to answer the question how to fix the code and why it is valid. Before starting to read my post, please, read the answers and comment discussions under those answers of Passer By and user2079303.
Basically the issue is that objects do not exist even though they do not really need anything, except the storage, to exist. This is said in the lifetime section of the standard, however, in The C++ object model section before it is stated that
An object is created by a definition (6.1), by a new-expression (8.3.4), when implicitly changing the active member of a union (12.3), or when a temporary object is created (7.4, 15.2).
A little bit tricky definition of object concept, but make sense. The issue is more precisely addressed in proposal Implicit creation of objects for low-level object manipulation to simplify the object model. Until then we should explicitly create an object by mentioned means. One of those that will work, for this case is new-placement expression, new-placement is a non-allocating new-expression, that create an object. For this particular case this will help us to crete the missing array objects and floating objects. The code below shows what I have come up with including some comments and assembly instructions associated with the lines (clang++ -g -O0 was used).
constexpr int Size = 10;
void* allocate_buffer() {
// No alignment required for the `new` operator if your object does not require
// alignment greater than alignof(std::max_align_t), what is the case here
void* buffer = operator new(Size * sizeof(int));
// 400fdf: e8 8c fd ff ff callq 400d70 <operator new(unsigned long)@plt>
// 400fe4: 48 89 45 f8 mov %rax,-0x8(%rbp)
// (was missing) Create array of integers, default-initialized, no
// initialization for array of integers
new (buffer) int[Size];
int* in = reinterpret_cast<int*>(buffer);
// Two line result in a basic pointer value copy
// 400fe8: 48 8b 45 f8 mov -0x8(%rbp),%rax
// 400fec: 48 89 45 f0 mov %rax,-0x10(%rbp)
for (int i = 0; i < Size; i++)
in[i] = i;
return buffer;
}
int main() {
void* buffer = allocate_buffer();
// 401047: 48 89 45 d0 mov %rax,-0x30(%rbp)
// static_cast equivalent in this case to reinterpret_cast
int* in = static_cast<int*>(buffer);
// Static cast results in a pointer value copy
// 40104b: 48 8b 45 d0 mov -0x30(%rbp),%rax
// 40104f: 48 89 45 c8 mov %rax,-0x38(%rbp)
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");
for (int i = 0; i < Size; i++) {
int t = in[i];
// (was missing) Create float with a direct initialization
// Technically that is reuse of the storage of the array, hence that array does
// not exist anymore.
new (in + i) float{t / 2.f};
// No new is called
// 4010e4: 48 8b 45 c8 mov -0x38(%rbp),%rax
// 4010e8: 48 63 4d c0 movslq -0x40(%rbp),%rcx
// 4010ec: f3 0f 2a 4d bc cvtsi2ssl -0x44(%rbp),%xmm1
// 4010f1: f3 0f 5e c8 divss %xmm0,%xmm1
// 4010f5: f3 0f 11 0c 88 movss %xmm1,(%rax,%rcx,4)
// (was missing) Create int array on the same storage, default-initialized, no
// initialization for an array of integers
new (buffer) int[Size];
// No code for new is generated
}
// (was missing) Create float array, default-initialized, no initialization for an array
// of floats
new (buffer) float[Size];
float* out = reinterpret_cast<float*>(buffer);
// Two line result in a simple pointer value copy
// 401108: 48 8b 45 d0 mov -0x30(%rbp),%rax
// 40110c: 48 89 45 b0 mov %rax,-0x50(%rbp)
for (int i = 0; i < Size; i++) {
std::cout << out[i] << " ";
}
std::cout << std::endl;
operator delete(buffer);
return 0;
}
Basically all new-placement expressions are omitted in the machine code even with -O0. With GCC -O0 operator new is actually invoked and with -O1 it is omitted as well. Let us forget about formalities of the standard for a second and think straight from practical sense. Why would we need to actually call the functions that are doing nothing, there is nothing that prevents it being a working without those, right? Because C++ is exactly the language where the whole control over the memory is given to the program, not to some runtime libraries or virtual machine, etc. One of the reason I might think here is that the standard again gives compilers more freedom on optimizations restricting the program to some extra action. The idea might have been that the compiler can do whatever reordering, omitting magic with the machine code knowing only definition, new-expression, union, temporary objects as new objects providers that guide the optimization algorithm. Most probably in the reality there are no such optimizations that will screw up your code if you allocated memory and did not call new operator on it for a trivial types. Interesting fact is that those non-allocating versions of new operator are reserved and not allowed for replacement, may be this is exactly meant to be the simplest forms telling the compiler about a new object.
