C23 will make calling realloc with a size of 0 into undefined behavior. [1]

[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf

That falls under things that were already undefined or impossible to use properly before.

Older standards said "it is implementation-defined whether the old object is deallocated". This didn't really work well:

- if realloc(..., 0) returns NULL if it freed the object, then you have confusion with error cases. strtol already has this kind of interface and it's unusable

- if realloc(NULL, 0) returns NULL and does nothing it does something different than malloc(0). Some chose to make it do something different, some chose consistency with malloc.

- if you choose consistency with malloc then realloc(NULL, 0) likely will end end up inconsistent with realloc(ptr, 0) where ptr is not NULL. On BSDs the two are consistent but also different from any other platform, so portable code could not rely on realloc(..., 0) doing something known: either you had possible double-free bugs on some platforms, or you had a memory leak.

I'm very unhappy that they chose to make it UB rather than mandating a behavior, but in portable C89 calling `realloc(ptr, 0)` is always a bug in your code, and it was an insane thing to declare implementation-defined originally.