Security reports from Google and Microsoft's teams prove otherwise.

Also let's not forget that C exploits go back to the 80's, when most of us where doing full application in Assembly.

Supposedly we knew our pointers pretty well.

> Also let's not forget that C exploits go back to the 80's, when most of us where doing full application in Assembly.

I'm not sure this statement adds anything to your argument. "Exploits go back as far as the language was in common use" doesn't really mean anything.

I'm sure Ada has had exploits, especially around its early lifetime. But its a language that's supposed to be safe.

The existence or non-existence of exploits isn't very interesting. The rate that users make vulnerable code is more interesting. The fact that remote-code execution vulnerabilities are still very common in C codebases even after people and the ecosystem have had decades to learn the ins and outs of C is concerning. Maybe the rate of RCE occurrences in C codebases has gone down over time as people have been educated about vulnerabilities more, but I would guess that the rate of RCE vulnerabilities in C codebases is still much higher than the rate ever was for safer languages.

> The existence or non-existence of exploits isn't very interesting. The rate that users make vulnerable code is more interesting.

Yes. Exactly. Exploits having existed for a long time isn't interesting or relevant.

I offered no defence of C. Just that the point wasn't relevant to the argument, one way or the other.

Pjmlp's post was directly responding to this part:

>People who understand these essential basics, e.g. by starting with Asm, are going to be far less likely to make these sorts of mistakes and write less buggy code in general.

Userbinator's post continues and seems to paint the ecosystem as getting worse over time, as if it were much better in this area in the past. Pjmlp's point was that even the original C users who came from assembly, who were presumably more familiar with the essential basics of assembly and memory management, still pumped out vulnerable code as we see today. It doesn't seem like having a userbase made up of experienced assembly programmers is enough for C to be predictably safe.

And C pre-89 is rather different than C11. The language changes, so comparing that which wasn't even specified against what we have to do isn't an argument one way or the other.

Some pre-89 code won't even compile today without putting in considerable effort.

Sure it is, a couple of CVE queries plotting C related exploits per year.

Morris worm was the first widely know C exploit, which still gives us about 30 years of exploits to look into.

Regarding how many exploits other languages have, for starters not memory corruption due to out of bounds access, integer overflow or implicit casts, as Algol derived system languages, since 1961 (8 years before C was even an idea), had checks for those kind of errors.

C only made it to fame, because original UNIX could not be sold and its source code tapes went from university to university.

Had it not been so, probably we would be using Bliss, PL/I, Mesa, PL/S, and not having arguments how good one needs to be to write code that doesn't allow for memory corruption errors.

Exploits having existed for a long time isn't interesting or relevant.

Exploits being consistently discovered over a long time is, and does help your argument.

"Rather different" is a bit much. I've been working with C since the 1989 or so. Other than K&R style function declarations / prototypes, C feels like it has barely changed over the years. It certainly hasn't changed as much as C++.

stdlib was introduced in '89. I specifically said pre-89, because this is what many C programmer's today depend on. malloc and free were brand new in '89 (mmap and friends didn't even exist yet). Instead you'd be playing with calloc and alloca.

Here's one for how safe that was: alloca could not guarantee the pointer it handed you is either valid, or the size you requested.

POSIX.1 only came along in '88 (with our first definition of stdlib). Whilst IO had mostly stabilised by that point, there were still plenty of platforms that didn't use the Bells header (stdio.h).

Files, signals, floating point behaviour, process creation - none of that was standardised yet.

You may be off by a decade. malloc and free existed long before 1988. I can find evidence of it going back as far as 1979 with 7th Edition Unix: https://en.wikipedia.org/wiki/Version_7_Unix http://man.cat-v.org/unix_7th/3/malloc

Most of what was defined by POSIX already existed on common platforms, like SunOS, before it was formally standardized. SunOS 4.0 even had mmap in early 1988! (See https://archive.org/stream/bitsavers_sunsunos4.erenceManual1... )

> It's really just arithmetic.

Understanding these concepts is not the problem. The problem is that even people who understand them very well regularly make mistakes when programming with them, and in C these mistakes have disastrous consequences.

> There's already a few comments about how "safer" languages don't really solve anything. They just push the problems up higher in the stack of abstractions...

The problems that exist higher in the stack of abstractions are present in C programs too. C just creates a lot of additional ways to subvert your program.

The fact that pointers and memory management may be so simple on paper, but programmers still routinely mess them up in the same way after decades implies that hoping programmers will finally just start getting it right all the time isn't a good solution. The idea that to solve the problem, everyone else just needs to finally get better, feels like the sort of thing one would say to feel superior to others writing buggy code rather than be a realistic path forward for decreasing the amount of bugs.

I used to have the attitude around vulnerable code of "The problem would be solved if everyone else was just better [like me]". I was desperately trying to prove myself. I'm good at finding and solving tricky bugs, including exploitable memory corruption issues. It felt nice having a thing that I was clearly superior to others in. I loved languages like C where I had a great knowledge of the footguns and I could save the day in. But then I got a good job, I no longer felt undervalued and needing to prove myself at all costs, and my attitude shifted.

I can't write the whole codebase myself or double-check everyone's work. This didn't really matter if I was just concerned with making myself look good, but if the thing I cared about was the product itself and stopping bugs (especially exploitable ones) from getting in to begin with, then it wasn't enough to drop in occasionally to save the day and chide others for not knowing enough about the specific footguns lying around. If there were a bunch of tools that were misused 2/3 of the times they were used in the company, then I could accomplish far more by finding and advocating for safer replacement tools than I could accomplish if I tried to double-check every time the old tool was used and endlessly reminded people that the flesh-magnetic hammer will seek out your thumb unless you know to use some specific swinging strategy.

>There's already a few comments about how "safer" languages don't really solve anything. They just push the problems up higher in the stack of abstractions

A program written in any general purpose language can have high-level bugs like forgetting to check the user's password when they sign in, but only languages with manual memory management make it easy to also have an exploitable memory corruption bug when handling the memory containing the user's password. Solving some kinds of issues is valuable because that can help reduce the count, likelihood, and severity of issues that do happen.

>The amount of anti-education authoritarian fearmongering in these discussions is disturbing. Then again, given how much everything seems to be rapidly moving in the direction of dystopian corporatocracy, perhaps that's not so surprising.

>... and when that time comes, what are the chances the "security" fearmongerers will just start blaming something else?

What possible ulterior motive do you think people advocating safer languages have? I really can't tell if this is parody. Do you think Mozilla made Rust as part of some bigger political narrative, rather than to just make it easier for them to write bug-free code?

It's not about being "better" insomuch as being knowledgeable. My comp. architectures course had a lab where we manually implemented a buffer overflow from seemingly innocuous code, and since learning Rust, I've started writing all my C/C++ code at work to manually check for nullptrs and bounds. If I get it right, branch prediction makes it free. If I don't have it at all, well shit, I might make a critical error in production code!