21 ms·
My favorite take on the severity of the UB problem, https://blog.regehr.org/archives/1520 https://blog.regehr.org/archives/1520 : > Tools like [Valgrind] are e
by oconnor663 7y ago
My favorite take on the severity of the UB problem, https://blog.regehr.org/archives/1520 https://blog.regehr.org/archives/1520 :
> Tools like [Valgrind] are exceptionally useful and they have helped us progress from a world where almost every nontrivial C and C++ program executed a continuous stream of UB to a world where quite a few important programs seem to be largely UB-free in their most common configurations and use cases...Be knowledgeable about what’s actually in the C and C++ standards since these are what compiler writers are going by. Avoid repeating tired maxims like “C is a portable assembly language” and “trust the programmer.” Unfortunately, C and C++ are mostly taught the old way, as if programming in them isn’t like walking in a minefield.
- jonhohle 7y agoStatic analysis tools should be the standard part of any build process, but especially with C/C++. I’ve mentioned before here, but when I found a reasonable number of bugs in critical library used throughout one of the FAANGs written by their most senior and brilliant engineers by running a fizzier on it for a few hours, my opinion of those languages changed. Integrating Valgrind and Clang’s checker, and running AFL for many CPU years was critical in unearthing some really funky crashes, hangs, overflows. Without those tools it’s not clear that those bugs would have been fixed. In fact, one of them affected me a few months prior and AFL helped uncover the codepath that was failing.
- enhray 7y agoI don’t think that this bugginess is an inherent property of these languages, because there are other practices that could lead to reduction in total bug count and severity, apart from integrating additional tooling. Out of curiosity, how many bugs you found by using these tools could have been avoided by using a “watertight” memory management system [0], with strong decoupling of pointer and object lifetimes? [0] https://floooh.github.io/2018/06/17/handles-vs-pointers.html https://floooh.github.io/2018/06/17/handles-vs-pointers.html
- AaronFriel 7y agoI'm curious who the target demographic is for this, people who think they need bare metal performance in a language that gives them access to bare pointers, know that most humans aren't capable of following Uncle Ben's adage[1], and then voluntarily give it up while insisting they need it? I think almost any JITed memory safe language will be faster than using handles for all object access. At least Java, .NET, JS, etc under the hood can avoid "double dispatch" of memory access. And you can use things like arenas to ensure same objects are allocated adjacently, etc. [1] With great power comes great responsibility
- saagarjha 7y agoThe solution presented solves "memory corruption" from the point of not having undefined behavior, but it doesn't really protect against "I accidentally created an index that has nothing to do with memory I manage, but is still 'in bounds' to the code that handles lookup".
- shadowgovt 7y agoEvery language has some expression weaknesses, and C/C++'s are such that the languages make static analysis tools mandatory for correct code (much like Python makes every-line-is-executed unit tests mandatory for correct code).
- stiray 7y agoWhat is profoundly pissing me off are bunch of hipsters on the internet that are using xyz language and are constantly trying to compare everything to C. We are faster, we are better, we are more portable, we have JIT, we have reflection... and so on. Who cares what your tool for solving the problem is. Use Java, use JS, use python, go, rust... whatever suits for the task. Why do you want to compare yourself to C. Just stop it. No one with enough expirience in coding will ever care what language you have used to acomplish the task. Unless the task is going to be purely written, slow, buggy, CPU consuming, will have security issues and so on. This can be acomplished with half-baked (I hate the expression, but sorry) coding monkey in any language. Why do you even care about C. It doesnt matter, all that are complaining about it in whatever way possible or compare to it, will probably never be involved in a task where C excels, so why bother? --- jeffdavis: the problem is that people would like to use wrong tool for the job. And the fact that they cant frustrates them, blaming everything else except the fact that they picked the wrong tool. As you need expirience for picking the right tool. A lot of expirience or rather beeing fluent in all the tools. Which makes it a problem if you dont dedicate a lot of time to this. --- jeffdavis #2: > choosing the wrong tool really is a great way to understand your tools and the problem more deeply. YES! Exactly! I did mistakes, a lot of them, like pragma packing the structure and send it to system on other side of network in other endianness. Overwritting EIP number of times before I understood it. Or best one, translating command.com to my language using edit :D Used wrong call convention. But my goal was always to understand assembler. To understand C. To understand C++. And I have made quite a lot of code in all 3. Then learnt any language that crossed my way and it looked like interesting (Rust is still on my list) and used each in at least one project, hobby or not. Now everyone learns one or two languages, without any background knowledge and then starts to preach it, prove that language written in X is faster than language that X is written in and so on. Who cares! It makes me puke.
- tux3 7y ago> all that are complaining about it in whatever way possible or compare to it, will probably never be involved in a task where C excels, so why bother? I don't think that's a fair assumption. You may be underestimating the number of developers who have a need for a systems programming language.
- shadowgovt 7y ago> Be knowledgeable about what’s actually in the C and C++ standards ... turns out to be an extremely tall order; the 2017-11-17 working draft of the C++ standard is 1,448 pages in PDF format. At some point, I wonder when programmers who are required to care about correctness throw up their hands and say "This language isn't reasonably human-sized for a user to know they're using it correctly." At which point the immediate next question should be "Why don't you use something else?" (In my experience, the only sane counter-answer to that last question is "I'm programming on an architecture where the {C/C++} compiler is the only one with any real expressive power that anyone has ported to this physical system." This is an answer I understand; most other answers will raise an eyebrow from me).
- z92 7y ago> most other answers will raise an eyebrow from me Portability. A C library can be trivially linked with any other language. But one will be hard pressed using a python library form Ruby, for example.
- cozzyd 7y agoIndeed. C++ is relatively portable too (or at the very least, can be made to hide behind a C ABI in many cases) and it seems like Rust is as well. Whereas, if you have a library written in python that you want to leverage, you're forced to include a python interpreter. This sucks.