Except Algol, PL/I, PL/M and many others already existed and pre-dated the computers used to develop C on.
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously,they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
- C.A.R Hoare at his 1980 ACM Turing Award Lecture
Algol was created in 1960 and run in computers much more humble that the PDP-11.
> And second, the constant stream of news about trivial SQL injections, cross-site scripting vulnerabilities and other such things should make it plenty obvious that you can write unsecure code in any language.
Those don't suffer from memory corruption issues. So there is a whole class of security exploits one doesn't need to worry about.
True... and I bet the performance was significally slower. Also I think the portability in those languages was also limited.
Obvious, since those systems pre-dated PDP-11 hardware.
> Also I think the portability in those languages was also limited.
Have you ever coded C before ANSI C was approved?
It was only portable to UNIX itself, just like those other OSes and their systems programming languages.
Each C compiler outside UNIX implemented its own subset and semantics, hence why ANSI C had to adopt so much UB to avoid breaking too much code.
Well, I was actually referring to the equivalent running on PDP-11 (like Algol68)
> Have you ever coded C before ANSI C was approved?
>It was only portable to UNIX itself, just like those other OSes and their systems programming languages.
I meant machine portability. Before C, to have a lower level like performance you needed to use machine-specific assembly.
On workstations and mainframes there was hardly any difference to other heigher level system programming languages. In fact C prevented many compiler optimizations due to its aliasing and decay of arrays into pointers.
C gives you all those SQL injections, XSS, shellshock, etc. in addition to all memory unsafe exploits - it's a superset of vulnerabilities (actually, I'd not be surprised if C makes it worse, as the code is far, far more verbose and focused on minutia and hence higher-level logic failures are more difficult to notice.). And, going from widespread commercial software, the other issues seem to account for much less of the critical security bugs.
Even so, if they had some amazing backcompat reason to stick with C, they should have been sandboxing and otherwise limiting the impact of the apparently-inevitable, trivial memory corruption issues they're sure to have created.
The top comment made by the same person.
Though the comment seems to get reasonably upvoted, you're right that perhaps it's not a very high signal. Sorry.
Find me an unintended trivial SQL injection or cross-site scripting vulnerability in Rust. Or Elm or Ur/Web, if you prefer more web-oriented languages.
All you have done is demonstrate that there are languages other than C that one should not write in, either. But of course there are. You have not demonstrated that all languages have these problems to the same extent.
It is rather like arguing that since you can get concussions in football, and you can also get concussions in ice hockey, it doesn't really matter what sport you play. While it is technically true that you can get concussions from golf or cross-country running, it takes quite a bit of skill and (un)luck to make it happen.
Well, if there's no web support in rust, that's going to be kind of hard. There's no SQL injection "in C" either. For that matter, there aren't any buffer overflows in the C language.
Now, if you meant "in some rando web forum written in rust", I think you'll need to wait a bit. Let's wait until there's a forum with more than a dozen users, then I'll tell you how the developers fucked up.
e.g. crates.io does no such tracking, but it also just punts the problem completely to our postgres bindings and making sure to build queries separately from their args (and the postgres arg injection does escaping, presumably). But this is no static or novel guarantee. It's just Alex being a great developer and reviewing all the patches.
I wouldn't be floored if crates.io was exploitable.
Actually I know it is; [I've exploited it](https://github.com/rust-lang/crates.io/issues/176).
Rust solves many interesting problems, but it is no panacea for program correctness!
Suggesting that throwing thousands of lines worth of virtual machine behind a piece of code will solve security problems is shortsighted.
Can we please stop with the C bashing already? Each time there's a story about a buffer overflow, the top comment says how that would be impossible in Go, Rust, JavaScript or the next shiny thing.
First of all, hindsight is always perfect. I'm sure adopting C made sense at the time. We didn't use to stroll down the street with a supercomputer in our pockets you know.
And second, the constant stream of news about trivial SQL injections, cross-site scripting vulnerabilities and other such things should make it plenty obvious that you can write unsecure code in any language.