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.
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.
"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.
