Really? I had a look at the code and I would agree with the basic idea of eliminating errno and always using the return value.
> If you actually care about memory safety—which you should, as the CVE list shows—then why not use an actual memory-safe language?
Following the logic here, you seem to be implying that no-one except the irresponsible should use C.
There are some platforms (such as embedded systems) where C really is the only choice. But if you do have a choice? Then I don't think using C is a good idea.
I'm not sure if "irresponsible" is the right word, though. I think developers underestimate the risks of C's unsafety and/or overestimate their ability to properly deal with it. Hanlon's razor[0] applies.
That's never true. You can always use a higher-level, safer language that can compile to C. The result is C code but you never write it & avoid its pitfalls. Ivory language in Haskell, Ada-to-C, and Modula-2-to-C come to mind. Alternatively, you can use something even more primitive in a C subset or native assembly that it compiles to. OcaPIC or JavaCard come to mind. Astrobe Oberon is another for safe, low-level coding but not sure how its compiler works.
"This boot-loader, unfortunately, did not support loading any kernel images larger than 4 megabytes. This turned into a problem very quickly as it turns out that rustc is far less adept than gcc at creating succinct output. In fact, I was hitting this problem so early I was barely able to make a “Hello World” before having to stop working on rust code. Fixing this problem required rewriting most of the early boot code, all of which was x86 assembly ..."
Much of the software that we all currently rely on is in C, for example all of the common operating systems are in C, and the reliability of these operating systems shows very clearly that C is nowhere near as inherently dangerous as you claim it to be.
This seems highly likely, yes.
C was a good language at the time. It's still probably a very good teaching language for systems programming. But it's a bad language for anyone who wants to write software that needs to be used responsibly. It predates the entire idea that some people on the network might be hostile. It predates the knowledge that buffer overflows might be used for malice. It predates about 40 years of programming language research and security research, some of which has even shown results.
C also predates computers of modern speed; it was written at a time when interpreted languages were mostly unthinkable for serious software. There's no reason that, say, the manpage rendering tools (the most recent thing I had half a mind of exposing to the network) would be written in C today, but it was presumably the best tool for the job at the time.
It is no criticism of C to say that it has served us well but it is a bad choice for new software for clear and objective reasons.
Someone called Kristaps Dzonsons wrote a manual page renderer and a cgi/fastcgi library in C quite recently.
There were already powerful computers than the PDP-11, with more saner languages.