3 ms·
"How can I avoid being burned by C’s numerous and severe shortcomings?" The only solution is using a program analyzer which can prove the absence of certain er
by blub 7y ago
"How can I avoid being burned by C’s numerous and severe shortcomings?"
The only solution is using a program analyzer which can prove the absence of certain errors. Frama-C and Astrée come to mind.
Normal static analyzers are best-effort, will have both false positives and false negatives and will also miss errors. This is the difference between testing and verification.
Dynamic analyzers like ASan or valgrind depend on having good code coverage and good value domain coverage. The former should be obvious, the latter will ensure that error-prone code which fails only when variables have specific values is also flagged. E.g: adding two ints is defined for some value ranges, undefined behaviour for others.
Now the main issue with all of the above is that virtually no self-respecting C programmer will use a verifier, so while theoretically possible to write safe C, it is practically almost unheard of - safety-critical domains aside.
There is no good safe, user-friendly alternative to C, all of them are either much more complex languages (Rust, C++), or less performant (Swift, Go) or have tiny marketshare (D, obscure things like Zig, etc)
- skocznymroczny 7y agoD doesn't belong in this category. If anything, D should be put next to Rust, C++. D is a very complex language compared to C and it offers all the C++-like features like templates and OOP.
- keldaris 7y agoYou can use D's betterC mode, supported by the compilers. This avoids the D runtime entirely, there are no classes, exceptions, etc. You can still use templates and CTFE if you like (which can be awesome), but there's nothing forcing you to do that. You can just copypaste some C code, make a few syntactic changes to get it to compile and get a decent level of safety that way.
- pjmlp 7y agoJust yesterday I watched this ACCU talk about how many of those developers don't bother at all with static analysers or even basic unit tests. "C++ ecosystem: For better, for worse - Anastasia Kazakova" https://www.youtube.com/watch?v=43E5iYzrQn4 https://www.youtube.com/watch?v=43E5iYzrQn4 Although a C++ talk, she also touches C quite a few times, given the goal to get them to adopt C++ as safety improvement, and naturally how to tailor CLion to the markets they are on.
- 0815test 7y agoI find it hard to believe that you can seriously describe Rust as "much more complex" than C and recommend Frama-C in the very same comment! The point of all that "complexity" in Rust is precisely to enforce the use of patterns that will make a Frama-C-like analysis feasible and not overly complex, even for large codebases. This basically boils down to avoiding shared mutable access; not coincidentally, this is also what functional programming languages do! (That is, sequential mutability that's isolated to some part of the code can be modeled through constructs like the ST monad and is relatively benign; shared mutability is a whole other can of worms.)
- blub 7y agoI'm not recommending frama-C, I'm opining on what's necessary to write reliable C code. Much of Rust's complexity is not directly addressing memory safety, it's providing high-level language features. A C-with-borrow-checker would be very different from Rust.
- 0815test 7y ago"A C-with-borrow-checker" is a good-enough description of Cyclone, which is not that different from Rust and which was basically abandoned for Rust. Sure, Rust itself has a number of higher-level features, some of which are a bit problematic by comparison with C (e.g. monomorphizing generics lead to intermediate-code bloat, which causes long compile times) but it turns out that these features are practically needed, either to make programming-in-the-large more feasible or to abstract some underlying details from user-level Rust code so it can keep working even as the compiler and standard library evolve underneath it. C doesn't have these problems being a mature platform, but Rust still does.