Is using malloc for int undefined behavior until C++20

Question

I was told that the following code has undefined behavior until C++20:

int *p = (int*)malloc(sizeof(int)); *p = 10; 

Is that true?

The argument was that the lifetime of the int object is not started before assigning the value to it (P0593R6). To fix the problem, placement new should be used:

int *p = (int*)malloc(sizeof(int)); new (p) int; *p = 10; 

Do we really have to call a default constructor that is trivial to start the lifetime of the object?

At the same time, the code does not have undefined behavior in pure C. But, what if I allocate an int in C code and use it in C++ code?

// C source code: int *alloc_int(void) {     int *p = (int*)malloc(sizeof(int));     *p = 10;     return p; }  // C++ source code: extern "C" int *alloc_int(void);  auto p = alloc_int(); *p = 20; 

Is it still undefined behavior?

Answer 1

Is it true?

Yes. Technically speaking, no part of:

int *p = (int*)malloc(sizeof(int)); 

actually creates an object of type int, so dereferencing p is UB since there is no actual int there.

Do we really have to call default constructor that is trivial to start the life time of the object?

Do you have to per the C++ object model to avoid undefined behavior pre-C++20? Yes. Will any compiler actually cause harm by you not doing this? Not that I'm aware of.

[...] Is it still undefined behavior?

Yes. Pre-C++20, you still didn't actually create an int object anywhere so this is UB.