4 ms·
My point is that it is humanly impossible to write a bug-free program. In C and C++, bugs usually manifest themselves in UB. To make matters worse, compilers,
by kstenerud 8y ago
My point is that it is humanly impossible to write a bug-free program. In C and C++, bugs usually manifest themselves in UB.
To make matters worse, compilers, ever searching for diminishing returns on performance improvements, have been steadily making the CONSEQUENCES of UB worse, to the point that even debugging is getting harder and harder. These languages are unique in their growing user hostility.
- llukas 8y ago> growing user hostility You have excellent tooling (*sanitizer, static analysis, valgrind, ${WHATEVER}) and abstractions provided to do handholding for you (ie. unique_ptr). Most of that was created in last few years.
- pjmlp 8y agoCompletely wrong. Lint was created in 1979, during the mid-90's we already had Insure++, Purify and others, ages before of the free beer alternatives. Yet being free still doesn't help the large majority of C and C++ to actually use them, as proven at one of CppCon talks, where a tiny 1% of the attendees confirmed using any kind of analysers.
- minipci1321 8y agoHow well the attendees of CppCon represent the developer base of C++ projects which are in dire needs of these tools? Maybe they are so skilled the need does not arise?
- esrauch 8y agoEven people who work on the language spec can't really avoid writing code that hits UB without the help of sanitizers.
- pjmlp 8y agoThe amount of CVEs found per month on highly skilled projecs, with deep review processes, like the Linux kernel proove otherwise. As for how well, usually conferences like CppCon have the top of the tops.
- jcranmer 8y agoOne of the most eye-opening papers in this regard was the integer overflow checking paper (which Regehr was coauthor on), which found that every library tested invoked undefined signed integer overflow. This includes SQLite, infamous for its comprehensive testing, and various libraries whose sole purpose was to check if an operation would overflow without invoking undefined behavior. Belief that you are skilled enough to write C/C++ code that doesn't exercise undefined behavior either shows that you don't know what is undefined behavior or that you believe you are the best programmer to have ever lived.
- gpderetta 8y agoLint is not a whole program static analyzer and being free is a big deal. Your -second- third paragraph is, unfortunately, still correct though.
- pjmlp 8y agoSomehow other professionals manage to pay for what goes into their toolboxes, music case, kitchen knives, ....
- banachtarski 8y agoWell don't use it. You aren't the target customer because for me, fixing the performance bottleneck is a lot harder than finding a divide by zero, and I certainly don't want to pay for the compiler to check things like divide-by-zero without me asking it to. When I don't care about performance, I reach for a scripting language or something. It's a tool, don't get all emotionally worked up about it.
- dagenix 8y ago> don't get all emotionally worked up about it. Not constructive
- pjmlp 8y agoWe are entitled to be emotional about it, because we all have to use tools which have the misfortune to be written in C derived languages. Even if I don't touch those languages for production code, my whole stack safety is dependent how well those underlying layers behave, and how responsibile the developers were towards writing secure core. Which as proven by buffer oveflows in IoT devices not much.
- xmiller 8y agoSo where is your production code written in Ada or Pascal?
- pjmlp 8y agoAda cannot tell. Pascal was replaced by Java and C#.
- jacoblambda 8y agoAda absolutely can tell. Divide by zero throws an exception and buffer overflows are caught by essentially every modern compiler.
- 8y ago
- nickpsecurity 8y agoOn Linux side, these slides I got from Alex Gaynor illustrate your point really well: https://events.linuxfoundation.org/wp-content/uploads/2017/11/Syzbot-and-the-Tale-of-Thousand-Kernel-Bugs-Dmitry-Vyukov-Google.pdf https://events.linuxfoundation.org/wp-content/uploads/2017/1... There hasn't been much in terms of changes. Languages immune to classes of vulnerabilities by default and/or sound checkers that can catch all of them seem necessary. And by seem necessary, I mean massive, empirical evidence that most developers can't code safely without such alternatives even on critical, widely-used, well-funded projects.