4 ms·

If that was true then nobody would be fretting about unsafe memory access, and the primary source of bugs used in exploits wouldn’t exist. Unfortunately it isn

If that was true then nobody would be fretting about unsafe memory access, and the primary source of bugs used in exploits wouldn’t exist. Unfortunately it isn’t true, C let’s you write plenty of broken programs that don't fail at run time, despite making a complete dogs breakfast of your systems memory space, instead we get crap like Heartbleed instead.

usrbinbash 5y ago
Its also perfectly possible to write broken programs in languages that take care of all memory related issues: var ch chan bool for i := 0; i < 10; i++ { go func() { // do something amazing ch<-true }() } Oops, I just leaked 10 goroutines, because I forgot to `make` the channel instead of declaring it, so its nil and will block indefinitely. Unless the program encounters an complete deadlock of all gorutines, this will not crash anything, and the caller of this code has no way of knowing it happened. Broken code can be written in any language, no matter how much checks & convenience it offers.
- zkldi 5y ago
  You can write a forkbomb in any language -- that's besides the point. Some languages are easier to write broken code in than others.
- tialaramex 5y ago
  This depends on deciding that "broken code" is all the same, but it isn't. Suppose I screw up writing the GIF decoder for avatars on my forum web site and you are a bad guy who can create accounts and upload an avatar. If I write the decoder in C it is very possible that your bad files can seize control of the web server, spill user credentials, post nonsense, mine crypto-currency on my servers, anything. If I write the decoder in safe Rust, some of these things are much harder to pull off, and I need to be really incompetent to cause the worst harm - but you can likely cause a lot of mayhem still if I screwed up. But if I write the decoder in WUFFS, the best you can achieve is to have the decoder chew CPU in an infinite loop or something. There are no boundary misses, integer overflows, or anything like that in WUFFS. My decoder might render your weird input as a giant orange splodge, or, as I said, spin forever wasting CPU, but it can't accidentally become a reverse shell server, or send you credentials from my password database, such things are entirely impossible. This is because WUFFS is a special purpose language. There doesn't need to be a way to write these nonsense programs in WUFFS, whereas it must be possible in a language like C to achieve the "general purpose" designator. But this should encourage us to write as little as possible with these unnecessarily powerful languages, like the way you don't use a chainsaw to sharpen pencils.
- mypalmike 5y ago
  I don't see any memory getting unexpectedly stomped on. C is a great language, but it is absurdly common to accidentally write code that writes garbage to nearby memory, or can be exploited to do so. Such bugs are the cause of a vast number of security problems. This characteristic of C is simply not true of most other languages.
masklinn 5y ago
C++ has even formalised a concept of compilation false positives (due to issues like separate compilation, which make it impossible for the compiler to know that you’re linking incompatible artefacts).

usrbinbash 5y ago

Its also perfectly possible to write broken programs in languages that take care of all memory related issues: var ch chan bool for i := 0; i < 10; i++ { go func() { // do something amazing ch<-true }() } Oops, I just leaked 10 goroutines, because I forgot to `make` the channel instead of declaring it, so its nil and will block indefinitely. Unless the program encounters an complete deadlock of all gorutines, this will not crash anything, and the caller of this code has no way of knowing it happened. Broken code can be written in any language, no matter how much checks & convenience it offers.

zkldi 5y ago
You can write a forkbomb in any language -- that's besides the point. Some languages are easier to write broken code in than others.
tialaramex 5y ago
This depends on deciding that "broken code" is all the same, but it isn't. Suppose I screw up writing the GIF decoder for avatars on my forum web site and you are a bad guy who can create accounts and upload an avatar. If I write the decoder in C it is very possible that your bad files can seize control of the web server, spill user credentials, post nonsense, mine crypto-currency on my servers, anything. If I write the decoder in safe Rust, some of these things are much harder to pull off, and I need to be really incompetent to cause the worst harm - but you can likely cause a lot of mayhem still if I screwed up. But if I write the decoder in WUFFS, the best you can achieve is to have the decoder chew CPU in an infinite loop or something. There are no boundary misses, integer overflows, or anything like that in WUFFS. My decoder might render your weird input as a giant orange splodge, or, as I said, spin forever wasting CPU, but it can't accidentally become a reverse shell server, or send you credentials from my password database, such things are entirely impossible. This is because WUFFS is a special purpose language. There doesn't need to be a way to write these nonsense programs in WUFFS, whereas it must be possible in a language like C to achieve the "general purpose" designator. But this should encourage us to write as little as possible with these unnecessarily powerful languages, like the way you don't use a chainsaw to sharpen pencils.
mypalmike 5y ago
I don't see any memory getting unexpectedly stomped on. C is a great language, but it is absurdly common to accidentally write code that writes garbage to nearby memory, or can be exploited to do so. Such bugs are the cause of a vast number of security problems. This characteristic of C is simply not true of most other languages.

masklinn 5y ago

C++ has even formalised a concept of compilation false positives (due to issues like separate compilation, which make it impossible for the compiler to know that you’re linking incompatible artefacts).