4 ms·

Not this crap again. C libraries are not pretty but they have been out there for decades, they have been reviewed and used in production. There is no silver bu

Not this crap again. C libraries are not pretty but they have been out there for decades, they have been reviewed and used in production. There is no silver bullet, just because you use Rust it doesn't mean your programs will be completely safe. A lot of these C libraries were written in more innocent times where a small bug would not affect as many people as it would today. We live in a C world and I don't see that changing any time soon.

pcwalton 11y ago
> C libraries are not pretty but they have been out there for decades, they have been reviewed and used in production. The same was true of Fortran when C came around. I'm glad K&R didn't use this reasoning in 1978 to justify not rewriting things in their new language. > There is no silver bullet, just because you use Rust it doesn't mean your programs will be completely safe. Nobody is claiming that Rust eliminates all security vulnerabilities. > A lot of these C libraries were written in more innocent times where a small bug would not affect as many people as it would today. This isn't a positive!
Avshalom 11y ago
>We live in a C world and I don't see that changing any time soon. Of course it won't because every time an out-of-bounds array access gives attackers free reign of a system and some one says "hey guys this whole C thing is clearly blatantly terrible" every one else says "Not this crap again. C libraries are not pretty but they have been out there for decades, they have been reviewed and used in production." As if the libraries have been utterly static for decades and aren't infact full of holes and bugs, which is exactly what brings on the call to rewrite things in Ada/Rust/SML/Lisp Then they always say "There is no silver bullet, just because you use Rust it doesn't mean your programs will be completely safe." As if there's no reason trying to improve things unless you can jump directly to perfect. they make excuses like "A lot of these C libraries were written in more innocent times where a small bug would not affect as many people as it would today." as if we still lived in those innocent times. And then they inevitably wave the call to action off by appealing to the status quo with some line like "We live in a C world and I don't see that changing any time soon." and so even though there's no reason we couldn't start re-writing things (especially in Unix an OS that constantly brags about being built from loosely coupled parts) in a better language we never get a critical mass together.
- latenightcoding 11y ago
  I see what you did there
unscaled 11y ago
My real gripe with C is that it was designed to be insecure ON PURPOSE, and many people in the OSS world hold the religious view that this is a good thing. C's primary design goal that overrode everything else was easy implementation. In order to keep a dumb compiler, the preprocessor was used instead of a proper module system. For the same reasons, the standard library is full of non-reentrant functions relying on global state, unbounded string manipulation functions or bounded string functions with ambiguous off-by-one properties, vaguely defined data types and so on. If there's one reason to do away with C, is to do away with all the stubborn programmers who clutch their copy of K&R and think everything must be done in the "C way". To paraphrase Linus' on C: you'd want to avoid C just to avoid this type of C programmers. They could be amazing coders, but not if you care about security (and you should).

pcwalton 11y ago

> C libraries are not pretty but they have been out there for decades, they have been reviewed and used in production. The same was true of Fortran when C came around. I'm glad K&R didn't use this reasoning in 1978 to justify not rewriting things in their new language. > There is no silver bullet, just because you use Rust it doesn't mean your programs will be completely safe. Nobody is claiming that Rust eliminates all security vulnerabilities. > A lot of these C libraries were written in more innocent times where a small bug would not affect as many people as it would today. This isn't a positive!

Avshalom 11y ago

>We live in a C world and I don't see that changing any time soon. Of course it won't because every time an out-of-bounds array access gives attackers free reign of a system and some one says "hey guys this whole C thing is clearly blatantly terrible" every one else says "Not this crap again. C libraries are not pretty but they have been out there for decades, they have been reviewed and used in production." As if the libraries have been utterly static for decades and aren't infact full of holes and bugs, which is exactly what brings on the call to rewrite things in Ada/Rust/SML/Lisp Then they always say "There is no silver bullet, just because you use Rust it doesn't mean your programs will be completely safe." As if there's no reason trying to improve things unless you can jump directly to perfect. they make excuses like "A lot of these C libraries were written in more innocent times where a small bug would not affect as many people as it would today." as if we still lived in those innocent times. And then they inevitably wave the call to action off by appealing to the status quo with some line like "We live in a C world and I don't see that changing any time soon." and so even though there's no reason we couldn't start re-writing things (especially in Unix an OS that constantly brags about being built from loosely coupled parts) in a better language we never get a critical mass together.

latenightcoding 11y ago
I see what you did there

unscaled 11y ago

My real gripe with C is that it was designed to be insecure ON PURPOSE, and many people in the OSS world hold the religious view that this is a good thing. C's primary design goal that overrode everything else was easy implementation. In order to keep a dumb compiler, the preprocessor was used instead of a proper module system. For the same reasons, the standard library is full of non-reentrant functions relying on global state, unbounded string manipulation functions or bounded string functions with ambiguous off-by-one properties, vaguely defined data types and so on. If there's one reason to do away with C, is to do away with all the stubborn programmers who clutch their copy of K&R and think everything must be done in the "C way". To paraphrase Linus' on C: you'd want to avoid C just to avoid this type of C programmers. They could be amazing coders, but not if you care about security (and you should).