C skill issue; how the White House is wrong
felipec.wordpress.com
felipec.wordpress.com
In this very report, Delphi/Object Pascal is listed as a representative of the "safe" languages, which is obviously wrong and calls the credibility of this report into question.
> C is superior to Rust in certain scenarios and in the right hands
That's not the point. C is obviously used in safety and security critical applications since decades and there are standards (e.g. MISRA guidelines, RTCA DOs) and tools which support us to do so. Even if languages like Rust avoid some errors which often occur in C (if the mentioned standards and tools are not applied), there are still a lot of things which can go wrong and make systems unsafe or unsecure, even when using Rust instead of C. It is naive (and dangerous) to assume, that by just using a language like Rust the resulting system would be safe. The programming language is just one of many protective measures that are required for critical systems.
Regarding your arguments: you are essentially stating that the risk of a technology depends on the maturity of the people using it. This is self-evident and manifests itself everywhere in daily life; for example, we use kitchen knives even though they are potentially dangerous; we use them anyway (and don't ban them), but don't put them in the hands of children, or only from a certain age with appropriate instruction and control. It's actually that simple and obvious, isn't it?
Sometimes the obvious needs to be stated.
Notwithstanding the best "ace / sniper" C developers and modern compilers, scanners, fuzzers, etc., C continues to be unsafe due to undefined behavior and how easy it is for anyone (including experts) to make mistakes:
If we are honest with ourself, and avoid Big Tech brain washing, on the life cycle of many software components, ironing "issues" in assembly is done on the long run and does exclude de facto "issues" spawning due to ever changing machine code from compilers.
- In the first one, there is advocacy for replacing (pointer == NULL) with (!pointer). I have no issue with either, but to me this sounds like canonical bikeshedding. I would certainly not argue that experts use only (!pointer) and beginners only (pointer == NULL).
- Then it advises replacement of a malloc()ated struct with an on-stack variable containing the same struct (fine so far, why not), then says "the assembly" is even superior if we make that variable "static". This completely glosses over the fact that those three options (malloc, on-stack, static) have completely different legitimate use-cases.
- In the second exhibit, there is a comparison of "glib-style" linked-list (in which the payload is separate, with pointers to it in the linked list), with "kernel-style" linked-list (linked-list pointers as a member structure in the payload structure). The author argues that the latter is what "ace" C coders do. Again, they have completely different use cases. Say you have a large payload structures in an array, and you want to represent a subset of them. "glib-style" can be the right approach then.
- The third exhibit, says "ace" C coders replace "fopen()/fread()" with "mmap()". They do mention in passing the small problem of portability (saying this is solved by just adding #ifdefs and having a separate codepath for Win32). Besides the obvious issues with that, what happens if the input is a pipe?
I find it particularly funny when the article so prominently mentions Dunning-Kruger.
* I did not say the variable being static was "superior", I said they were advantages.
* If you have a large array and want a linked list with pointers to the elements, then just create a `struct node` with a pointer. The linux-style intrusive linked-list allows both use cases.
Dunning-Kruger shows again that people who believe they are proficient at reading technical articles are not as proficient as they think they are.