3 ms·
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 prob
by citrin_ru 6y ago
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.
- MaxBarraclough 6y ago> 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.