OMG! Please do not add more undefined behaviour!
We really need less UB, not more! What was wrong with 'implementation defined' as in C17? UB means that code that exists will now break if a new compiler decides that it can be smart. And we know how inventive this can get, right? Like removal of 'if(new_size==0) {...}' if the compiler can prove that 'new_size' went into 'realloc' before.
First, the specification for malloc() says you can call it with size 0 and it will still return a pointer to zero bytes; this means an array of bytes having size zero is legal.
Second, having the compiler detect when realloc() is called with size zero changes what should be a library call into an intrinsic, whose very presence in the code is determined by the value of its arguments[0]. If you're going to do that you might as well just put exceptions in the language!
[0] Most compilers assume UB "can't happen" and just remove the offending code altogether.
To be clearer: UBs (specifically the assumption that they don’t happen) get translated into constraints (since C’s type system is extremely weak UBs are a very valuable source of such constraints to optimising compilers), those constraints are then propagated (forwards, and backwards, and upwards due to inlining) and any path for which the constraint does not hold can be considered dead.
> If size is 0, then malloc() returns either NULL, or a unique pointer value that can later be successfully passed to free().
So it's not really an array of bytes of size 0.
All RAM is an array of bytes, so any pointer to real memory(vs. virtual memory) is a pointer to an array of bytes.
malloc () doesn't return even that. It returns 'void *' which isn't of much use without a further upcast. The required upcast, and the rest that follows, is the coder's own idea of what happens.