That is an incredibly broad generalization. Perhaps you were implicitly assuming some qualifiers? :)
---
"..that's why we have linters, static analyzers, style guides, compiler options and warnings.."
But all those things are still just glorified retrofits on the job of the language. Are there any examples where a new library in a new domain adds inabilities that weren't originally enforced (or even conceived of) in the language?
One example I can think of is reading/writing files. The original C had simple numbers for file descriptors, which meant that in a large application you might try to read from a write-only fd, or vice versa. The C++ standard library solved that by creating separate types for istreams and ostreams. No reason we couldn't apply that idea to C as well.
On a tangent, I'm fascinated by the fact that Go hasn't bothered to steal that idea. For example, a goroutine can read or write any of the channels it has access to. If you try to juggle too many at once, that might cause the odd typo bug. It'll be interesting to see if source/sink channel types ever get retrofitted to Go in a decade or so.
Channels can be designated as receive-only or send-only in variable and function declarations:
ch := make(chan int, 1)
var send chan<- int = ch
var recv <-chan int = ch
send <- 1 // ok
<- recv // ok
recv <- 1 // invalid operation: recv <- 1 (send to receive-only type <-chan int)
<- send // invalid operation: <-send (receive from send-only type chan<- int)So really, your argument only applies to public facing servers or web browsers. Unless you're writing one of those, I think your argument is weak.
Or, you know, literally anything touching a file format that might be downloaded. PDFs, word documents, images, zip files, movies, music, sounds, icons that show up in your file explorer, user profiles, any sort of web client (email, games, chat, wget, package managers, ...) lots of poison apples out there.
This kind of nonsense is why the best advice to handling USB drives you find on the ground is to toss them in a fire barrel - everyone thinks they're "behind a firewall" and that they're totally protected! They have all the protection of a wet tissue in a hurricane.
Oh, but I'm just writing a terminal! I don't touch file formats! It's safe to auto-execute commands in response to pasted newlines! ...and then you've helped enable the spread of malware through clipboard hijacking Javascript. Oops.
Firewalls are not a panacea. Firewalls are a roadbump.
> Unless you're writing one of those, I think your argument is weak.
I think your security is borderline nonexistent. I think I cannot trust you with C. I think someone is probably in your systems if you're in charge of the security side of IT, of anywhere of significance, unless you delegated enough responsibility to make you a figurehead.
I mean no offense by this. A lot of reasonably talented and smart programmers make the same mistake as you, and go write a bunch of exploitable vulnerabilities in C as a result. It's not like you're one of those madmen disabling ASLR, NX, stack cookies, or some of the many other mitigation techniques being used to try and clean up after this tragedy of our times. ...right?
You really don't get it, but your arrogance is overwhelming. I don't care who you trust.
> I mean no offense by this.
Yes you do.
Then point out what I'm missing.
However, giving you the benefit of the doubt - There tens of thousands of programmers out there (myself included) who write software to analyze data. We don't make "apps" for users, and we don't download random PDFs or MP3s for input. Your view is so limited, you can't even imagine software that isn't a product or a tool for advertising, but trust me - a lot of software is written in other environments, and malicious users or malicious data is not a real concern.
Anyways, don't bother to reply. I'm sure you won't admit you're wrong, and I'm not interested in continuing this discussion.
I appreciate that.
> There tens of thousands of programmers out there (myself included) who write software to analyze data. We don't make "apps" for users, and we don't download random PDFs or MP3s for input. Your view is so limited, you can't even imagine software that isn't a product or a tool for advertising, but trust me - a lot of software is written in other environments, and malicious users or malicious data is not a real concern.
Ahh. It's funny - you think I can't think of all the software where security isn't an issue, and I think you can't think of all the software where security is an issue.
I'm aware that there is software where, rightly, security isn't a huge concern. It exists. Some software for crunching data internally counts! And some software is written where the front door is wide open anyways. But the scope for software where security isn't a concern sure as shit isn't "everything but public facing servers or web browsers", as I took you to imply. It's also not "everything but products and advertising tools". Point of sales systems, industrial control software, internal financial software, routers, telecom infrastructure... all kinds of wonderful "internal", bespoke systems, that most definitely need to care about security and protection against malicious users, or malicious employees. Industries where mandatory vacations are a security policy against fraud, where your software will be generating audit logs, where defense in depth matters against external threats even if you could trust your employees.
Which are just chock full of C programs. Sigh.
> I'm not interested in continuing this discussion.
Fair enough. Thank you for taking the time you did.
> Look, you're just another arrogant novice who runs around telling people how to be safe
Yeah, probably. Not so arrogant as to be certain I can think of every reason my software might actually need to care about security, or to try and write security critical C in good conscious, though.
> so you can convince yourself that you're safe.
I'd never succeed at that. Safer, maybe, but never safe.
> Maybe you'll grow out of that, or maybe you'll stay obnoxious forever.
For the sake of progress and a safer future, let's hope for the latter.
Which tend to be based on heuristics, rather than any sort of rigorous foundation. There's no shortage of static analysis tools for C and C++ that reject good code and accept bad code.
> style guides,
Which can be very onerous, limiting your ability to define useful abstractions, leaving you with just the bad parts of the base language (e.g., Google's C++ Style Guide).
> compiler options and warnings,
No amount of compiler options or warnings will force you to use an abstract type, well, abstractly, in a language that has unrestricted memory access (C and C++), unrestricted reflection (Java, .NET, anything dynamic), or both (some Common Lisp implementations).
> and ultimately code reviews and good taste.
If only the latter weren't in short supply...
C is one of the most used languages in the world, and the number of programmers is surpassed perhaps only by a handful of languages. That alone tells me any generalisation you make about C programmers is most probably erroneous.
One a name and one phrase changed but it's still technically true. Clearly something wrong with your argument unless you think COBOL is also superior to other languages due to uptake.
I think the big problem (and sometimes benefit) of old languages is their culture. For example, C programmers don't trust anything written since K&R. This is both good and bad. Creating a new language doesn't force existing communities to change; it means creating a new community and either waiting for the old ones to die off, or (ideally?) driving them into obsolescence.
I remember when Wikipedia was new and there were lots of studies finding errors in their articles. Instead of replacing Wikipedia, those techniques for finding errors were simply incorporated into the editing process (as much as possible). I wish that as new classes of bugs came onto our radar, we could go back and refine old code instead of throwing it out with the bathwater. (Even OpenSSL wasn't beyond saving, judging by BoringSSL and LibreSSL. These projects still need more work, of course.)