Definitely. Though Linux code has probably been tested more thoroughly, and run through more static analysis, than any other C code base. That does help me sleep a little better at night.

Interesting, I had the same job in mid to late 00s, although I wasn't a consultant so my sample was the company's codebases (of which there were a lot because we built a lot of embedded systems on top of vxworks that did a lot of network communications, sometimes in very niche protocols), not necessarily the codebases of company's that are worried enough that they hire a consultant. That was right around the time when compilers and security tools were becoming available that could flag nearly every possible problem. At that point false positives became a big challenge.

What years were you a consultant reviewing C applications?

What percentage of non-C applications did you review? I suspect C has enough footguns to be an issue, but its popularity, especially in low-level software (kernels, codecs, firmware) ensures that it'll show up in security issues regardless of how bad the languages itself is.

We don't even have a string library in C. Strings are Unicode, not just zero-terminated buffers. You cannot find strings, nor compare them. In the kernel you have filesystems and login systems using unidentifiable names. Because the kernel has no identifier support.

And for insecure standards, the committees rather want to eliminate the safe functions, than fixing the spec bugs or add u8 support.

It's easy to say "You shouldn't have security bugs baked into the standard library" but it's a lot harder to say, "we're breaking decades worth of working code by removing some functions that have been part of the standard lib and were widely used."

I mean even an off by one is a security issue

> Apparently Mozilla, Microsoft, Google, IBM and all companies slowly moving their system infrastructure to Rust don't know enough C.

They are moving that direction because of the safety promise that Rust offers and it is a "hot" language with a bunch of momentum behind it.

Yeah, I find it astonishing to find C programmers that see no problem, even though I think it would be reasonable to say that they see no reason to change. It's mind boggling.

Have they not worked on large projects with other developers? Have they not seen the myriad of ways things can silently go wrong for seemingly no technical benefit? (although I know there's often less obvious reasons, for eg. UB, performance, platform specificity, etc.)

All that, said I do think the following might be reasonable: > "nah, C is fine, you just avoid this and that, use these tools, etc."

I guess you mean they write off the risks entirely? You should never be this "handwavy", and should always take the risk seriously, especially with a language like C. However, I think it's fair to say, that C is a good choice, many of the risks can be mitigated, and it's not THAT big a deal. In which case, the above doesn't seem that absurd.

Following basic common sense and making an effort to identify and eliminate some of the sketchier situations, backed by some really good integration testing, can really help. I feel reasonably safe under those circumstances (I mean not really, but other languages can be "unsafe" too). A huge chunk of the really evil things I've seen have been the result of taking absurd risks, and/or disregarding the rules entirely. If you were paying attention and "trying" to write good C code, they would never happen; these aren't just individual developer things, but project wide. Eg. I had a compiler that didn't even warn for implicit functions... jerk move by TI, but that should be flagged and dealt with. Instead, the team just thought "great no compilation errors".

I will say there's a lot of developers that are just uninterested in any of this and will deliver some really, really sketchy C code. In their mind they're smart programmers and their code will just be right, and they don't seem to understand any of these issues. Just plow ahead and patch around the bugs, then move on to the next gig.

I had this argument with some of my management. There was a push to upgrade all of our libraries that were deemed "old" with no other criteria than "it's outdated." I can appreciate shiny new toys, but if you're not hitting bugs and things are stable, I'd rather put my effort into adding features to our codebase and not chasing down library bugs.

This is kind of one of those issues that can really cut both ways. I don't think it's the best attitude to say, "it's been working for years, so it's fine"; there could be subtle bugs, and areas rarely exercised. Still it often holds true. We all remember times we've meddled with something and messed it up. It seems that some of the low level code has been really heavily used in many different ways, and seems to just work. Especially if it's not safety/security critical (and maybe even if it is), it could be a poor use of resources trying to fix something that isn't broken.