Notably, the C standard <i>does</i> have an undefined behavior annex, Annex J.2, since C99. It's not mentioned in the post, and this omission in tandem with repeated usage of "C and C++" at various points might suggest otherwise to some people.
> We also will require future proposal authors to keep the annex updated if they add or remove undefined behavior. They are making undefined behavior an explicit topic to be discussed when reviewing a proposal.<p>This is great.
I know, the goal is (in short) a listing of expected undefined behavior, which could improve security if developers follow along.<p>But isn't putting undefined behavior into the standard an oxymoron, kinda?
Great stuff. It looks like a ton of upfront work, but will greatly improve the standard, and shouldn't be too hard to maintain once it's complete.
I love how in C++ there seems to be this security issue, and now hundreds of people try to come up with different ways on how to tackle the problem.<p>Everybody wants to help and spend their free time on it.<p>You don't see this in other languages so much. People just use those languages and "they" have to fix any flaws.<p>Also keep your bingo cards ready for people saying Rust does not have undefined behaviour.<p>I'm also not so sure Rust is even that safe. Yes it's memory safe but the languages with the most vulnerabilities is not C++. It's PHP, .NET, C, Java, JavaScript.<p>C++ is not an unsafe language. You can't make a language safe by adding an "unsafe" keyword end expect everything outside it to be safe. Else .NET and Java would be lower on the list than C++ because they do have bounds checks and they don't have raw pointers.<p>It's a bit of a false sense of security and a play of words this "unsafe" keyword in Rust.