C itself is also scary. Most other languages provide at least run-time safety; some provide great compile-time safety. C providing neither and being the most popular language for system software is what is really scary.
I guess part of what is scary about C is that it gives you the illusion of a high-level language, but unless you know all UB by heart, you might accidentally start working in assembly.
Isn't there at least a flag that activates warnings for stuff like this? I tried -Wall in both clang and gcc and they didn't say jack shit.
What do modern C developers do these days? Arm themselves with expensive advanced static analysis tools to their teeth?
I agree, C itself is kind of scary. And what's worse is that you've understated it a bit. You don't "start working in assembly," because some of the scariness is that your operations don't map nicely to assembly, as the compiler does its thing. For example, taking a pointer to something on the stack and adding an offset to get a pointer to something else on the stack would be reasonable to do in assembly, and fine if done correctly, but if you try to do the same thing in C it's a crapshoot as to whether the compiler will do what you expect, or whether it will decide to eliminate the whole chunk of your code because it can't possibly run, or something else.
Static analysis helps a lot, as does being careful about what you write. Most constructs aren't dangerous, so you can mostly avoid the scary ones, and take extra care when you need to use them. Not that this saves you all the time, but it helps.
I guess part of what is scary about C is that it gives you the illusion of a high-level language, but unless you know all UB by heart, you might accidentally start working in assembly.
Isn't there at least a flag that activates warnings for stuff like this? I tried -Wall in both clang and gcc and they didn't say jack shit.
What do modern C developers do these days? Arm themselves with expensive advanced static analysis tools to their teeth?
reply