Catch-23: The New C Standard Sets the World on Fire
This is written with quite a lot of hyperbole.<p>The predominant focus is realloc(pre,0) becoming UB instead of what the author misleadingly describes as useful, consistent behaviour. It is far from that, and that’s the entire reason that it was declared UB in the first place: <a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf" rel="nofollow">https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf</a>. Note that this wasn’t a proposal to change something, it’s a defect report: the original wording was never suitable.<p>The second part is the misconception about the impact of UB. Making something UB does not dictate that its usage will initiate the rise of zombie velociraptors. It grants the implementation the power to decide the best course of action. That is, after all, what they’ve been doing all this time anyway.<p>Note that this deviates from implementation-defined behaviour, because an implementation-defined behaviour has to be consistent. Where implementations choose to let realloc(ptr,0) summon the zombie raptors, they are free to do so. Don’t like it? Don’t target their implementation. Again, this isn’t a change from the POV of implementers - it’s a defect in the existing wording.<p>In this case, the course of action that any implementation will choose is to stick with the status quo. It is clearly not a deciding factor in whether or not you embrace the new standard, and to suggest otherwise is dishonest, sensationalist nonsense. The feature was broken, and it’s just being named as such.