Committees have limits

Posted Jul 25, 2024 9:17 UTC (Thu) by kleptog (subscriber, #1183)
In reply to: Committees have limits by CChittleborough
Parent article: GNU C Library 2.40 released

Indeed. I am struck by the parallels between this discussion and discussions in a completely different arena. A certain well-known grouping of sovereign states, when discussing some technical point where for $REASONS they each do things differently, sometimes choose to declare that an equivalent of UB.

This irritates larger businesses and consumer advocacy groups (in the role of users) because UB is Bad and declare that $SOMEONE should simply impose a choice by force and get everyone to fall in line. And on the other hand the sovereign states (in the role of compiler writers) claim they have always done things this way and a see no reason why they should change, because doing so will make a different group of people unhappy. And they would be severely annoyed if someone imposed a choice them (if that's even possible).

The end result doesn't really make anybody happy, but whether it's a real problem strongly depends on the topic. How many programs really use realloc() in a way where this behaviour causes problems?

Committees have limits

Posted Jul 25, 2024 9:49 UTC (Thu) by CChittleborough (subscriber, #60775) [Link]

Excellent analogy! I wish I had written something this good.

Committees have limits

Posted Jul 25, 2024 11:24 UTC (Thu) by Wol (subscriber, #4433) [Link]

> The end result doesn't really make anybody happy, but whether it's a real problem strongly depends on the topic. How many programs really use realloc() in a way where this behaviour causes problems?

Probably not a lot, because (my desired) behaviour was pretty much only MS C, as far as I can make out. But rephrase that as "how many programs SHOULD use realloc in that way" (as in "ptr = realloc(ptr, 0)") and I would say pretty much all. It makes "freeing and destroying" a pointer a single op, so long as you haven't made multiple copies of the pointer. A little bit of programmer discipline, and you've probably turned 99% of "use after free" bugs into a "dereference null pointer" crash.

Okaay, if you don't catch them all in testing you might get the odd DoS. But that's probably better than an exploit - or corrupt data, or a crash miles away from the bug site ...

It's an extremely useful defensive programming technique.

Cheers,
Wol