Herb Sutter on increasing safety in C++

Posted Mar 14, 2024 1:12 UTC (Thu) by pctammela (guest, #126687)
In reply to: Herb Sutter on increasing safety in C++ by atai
Parent article: Herb Sutter on increasing safety in C++

Backward compatible undefined behavior sure is the pinnacle of language design in the 90s /s.
The numbers speak for themselves and Rust is a capable alternative for even the hardcore cases. It's time for C/C++ to retire.

Herb Sutter on increasing safety in C++

Posted Mar 14, 2024 21:59 UTC (Thu) by pawel44 (guest, #162008) [Link]

< The numbers speak for themselves and Rust is a capable alternative for even the hardcore cases. It's time for C/C++ to retire.

Being capable doesn't mean it's a good replacement.

Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 18:44 UTC (Fri) by bartoc (guest, #124262) [Link] (1 responses)

UB is a consequence of standardization.

Much of Rust's UB corresponds exactly to LLVM UB, and C++ has more UB than just that, and sometimes implementations end up providing consistent behavior for some UB without going through the standards process (just by happenstance, and vendors have incentives not to differ from other implementations for "no reason"). C makes this even more obvious.

Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 23:01 UTC (Fri) by khim (subscriber, #9252) [Link]

> Much of Rust's UB corresponds exactly to LLVM UB

Not precisely. Some UBs were ingrained pretty deeply into LLVM and required patches to handle them.

One example is “forward progress” UB was ingrained into LLVM pretty deeply and it took a lot of effort to make it non-UB.

But it was critical for the ability to claim that normal, safe, Rust couldn't generate UB (at least not easy, without [ab]using soundness bugs in the compiler), so that was done.

> just by happenstance, and vendors have incentives not to differ from other implementations for "no reason"

We are way past the point where that was true. Just look on this [recent] gem. Someone have added this nice “optimization” which is pretty much [ab]uses UB to break code which it's author have always considered valid.

Is “we have saved 0.1% on some benchmark at the cost of putting few new mines on the well-trodden road” good enough justification?

> If people in the C/C++ community would have actually talked to each other then it would have been easy to change the rules (in the backward incompatible manner, mind you!) to make language safer.

But if C/C++ couldn't even accept any changed that would just make already existing code safer then what hope is there that these “security profiles” would be adopted by anyone?