3 ms·

One of these days, I will get around to writing my post as to why that take on undefined behavior is completely wrong. More to the point, though, the only chan

One of these days, I will get around to writing my post as to why that take on undefined behavior is completely wrong. More to the point, though, the only changes to undefined behavior in the C specification in newer versions (compared to C89) are either clarifying things that were already undefined behavior (e.g., INT_MIN % -1) or actually making some undefined behavior well-defined (e.g., allowing type punning via unions).

comex 5y ago
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 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf
- bonzini 5y ago
  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.
- plorkyeran 5y ago
  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.

comex 5y ago

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 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf

bonzini 5y ago
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.
plorkyeran 5y ago
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.