News for hackers. Stuff that matters.

A comment on Some Were Meant For C (2017) [pdf]. Parent comment

Re:Some Were Meant For C (2017) [pdf] by citrin_ru on Monday March 01, 2021 @03:18PM (#26307835)
1. Fixing/avoiding UBs requires discipline (and time) not all programmers have 2. Many programmers pointed to UB in their code would argue that it is not a problem at all - especially if code works for them and users don't complain about bugs caused by UB.

It would be interesting to make a following experiment: * find and patch UBs in multiple opensource projects which are relatively popular (at least used not only by an author) * send pull requests wich UB fixes and see which fraction will be closed as "won't fix".

It requires a lot of time, but may show that many developers don't care about UB.

[ Parent | on HN ]
Re:Some Were Meant For C (2017) [pdf] by MaxBarraclough on Monday March 01, 2021 @06:09PM (#26309773)
> 1. Fixing/avoiding UBs requires discipline (and time) not all programmers have 2. Many programmers pointed to UB in their code would argue that it is not a problem at all

These points aren't wrong, but it understates how pernicious undefined behaviour can be. As I stated earlier, even well-resourced high-profile codebases like Chromium and the Linux kernel play cat-and-mouse with security issues originating in undefined behaviour. It's not just a matter of hiring diligent coders and using the usual quality-control processes (testing, code reviews, static analysis).

It's possible for C/C++ code to be entirely free of undefined behaviour, but in practice this only seems to happen when formal methods are used, or when people use code-generators/transpilers to avoid writing C/C++ by hand.

[ Parent | on HN ]