There is also the issue of undefined and implementation defined behavior.
When developing on one platform for an extended period of time, it is human nature to forget which features are implementation defined as you use them day after day and then have unexpected errors/flaws when porting.
Undefined behaviour actually isn't the monster that most C language lawyers want you to believe it is. With tools like valgrind, address sanitizers and modern debugging toolchains, most of these issues can be caught. Compilers are also mature enough to issue warnings about the use of uninitialized variables, missing return statements or mismatched printf specifiers. Heck, Clang maybe has more than 250 -W options.
Knowing your tools and compiler switches is key. The reward is that the final production code can be very lean and performant, without any runtime penalties to provide safety.
Most people who complain about the dangers of C probably have used it in an unprofessional setting without any additional tooling. It's a bit like saying that all RWD cars are dangerous just because you've once driven a '92 BMW, disregarding any technological advancements since.
> Most people who complain about the dangers of C probably have used it in an unprofessional setting without any additional tooling. It's a bit like saying that all RWD cars are dangerous just because you've once driven a '92 BMW, disregarding any technological advancements since.
Actually, most of the people I know who think C is a problem that needs fixing are longtime professional compiler developers and people who work on security critical codebases. In fact, I don't know any compiler engineers who don't have serious reservations about C and C++. Those people know more about tooling and instrumentation than virtually anybody. It's precisely that knowledge that leads one rapidly to the conclusion that there are serious flaws in C for secure software that can't just be papered over with tooling.
It's usually C++ enthusiasts who are the ones trying (unsuccessfully, IMO) to argue that undefined behavior isn't a problem in practice.
Are you sure you aren't mixing causes and consequences?
I'd say that this is actually because undefined behaviour is hard (didn't say impossible) to get right at the human level that tools were, and still are, being developed.
UB and IB ( implementation-defined ) have not been a problem for me for a couple decades now. No advocacy here - I started using C because it was about all there was - but it's just a learning curve.
There was no direct cost to me because I was getting paid to learn this stuff on the job.
> With tools like valgrind, address sanitizers and modern debugging toolchains, most of these issues can be caught.
Most of these tools require support from an operating system. This is not the case when you do kernel programming. For some reason even existing tools are not popular among kernel programmers [0].
IMO, there are bugs that can be caught well a compile time without my effort, so why should I waste time on catching them at runtime?
I would better make love to compiler instead of having sex with debugger.
Any user action that you didn't have a test case for can provoke catastrophic UB that valgrind never saw, so catching most issues has almost no value. This is why every OS and every app I have ever used were always unreliable shit.
Undefined/implementation-defined behavior are necessary if you want optimal performance (unless the compiler requires formal proofs of correctness).
>it is human nature to forget
High-performance programming is a job the average human does not do. A professional programmer should use spaced-repetition technology to rise above human nature, and use tools like valgrind for extra safety.
Porting is it's own thing - you must seperate implementation dependent things and ... "business rules" fairly strictly if you are to keep it portable. I'd also strongly suggest a really comprehensive test suite that beats the snot out of the implementation dependent portions.
Somebody mentioned "scripting languages" - use the ability of scripting languages to construct combinators to write your tests. They migth even emit 'C' code.
When developing on one platform for an extended period of time, it is human nature to forget which features are implementation defined as you use them day after day and then have unexpected errors/flaws when porting.