7 ms·
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
by AgentME 7y ago
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.
- shakna 7y agoAnd 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.
- pjmlp 7y agoSure 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.
- shakna 7y agoExploits 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.
- icedchai 7y ago"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++.
- shakna 7y agostdlib 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.
- icedchai 7y agoYou 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 https://en.wikipedia.org/wiki/Version_7_Unix http://man.cat-v.org/unix_7th/3/malloc 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.erenceManual198805_78292584/800-1751-10A_SunOS_Reference_Manual_198805_djvu.txt https://archive.org/stream/bitsavers_sunsunos4.erenceManual1... )