2 ms·

> Many of memory corruption issues with C aren't a problem with the stronger type system of Algol and PL/* family of languages. This is probably just my lack o

> Many of memory corruption issues with C aren't a problem with the stronger type system of Algol and PL/* family of languages. This is probably just my lack of imagination, but, how would you get the same degree of control C offers over the memory layout of data structures (among other things), without giving up on safety, and using only 60's and 70's technology? Even (safe) Rust doesn't help in some cases, say, if you want a single dynamically allocated memory block containing an array of “m” integers followed by an array of “n” floating-points, where “m” and “n” are determined at runtime. Or are you just going to say this is never desirable? > If it wasn't for that, most likely Rust wouldn't be needed, at least not in the way it looks like. Because we would still be using tagged architectures, and every machine instruction would incur in the cost of checking these tags? Or because non-determinism is never too big a price to pay for safe memory management? (Never mind the fact that programs also need to manipulate other resources that aren't as plentiful as memory, and thus require eager reclamation.) No, thanks.

derefr 11y ago
It might be desirable now, but those '60s/'70s OSes probably weren't dynamically allocating memory ever. They'd make a buffer in [their equivalent to] the .BSS section that was M×sizeof(int), and another that was N×sizeof(float), and then they'd process records through those buffers blockwise.
- pcwalton 11y ago
  Exactly. In the '60s and '70s malloc was a luxury that most programs didn't have, and so Rust's facilities weren't needed to ensure safety. That doesn't describe the state of play in 2016. Those safer languages from the '60s and '70s would also be inadequate to ensure safety today.
- catnaroek 11y ago
  > It might be desirable now, but those '60s/'70s OSes probably weren't dynamically allocating memory ever. Those systems suddenly seem a lot less impressive now. While the lack of dynamic resource management poses other problems (e.g. determining up-front if the system has enough resources to complete the given task), I can't imagine this being more challenging than implementing a modern runtime system (JIT compiler, garbage collector, green thread scheduler, etc.).
pjmlp 11y ago
Some of the languages that come to mind without GC, Algol and its variants, NEWP, Mesa, Modula-2, Ada. With GC, Lisp, Smalltalk, Modula-2+, Modula-3, Eiffel, Oberon, Oberon-2, Active Oberon, Component Pascal,.... Keeping the focus on the ones without GC, all of them were use to build full stack mainframes, so of course they supported dynamic structures. Just the memory was measured in KB not GB. And, yes they did not prevent the programmer of doing a double free or calling free in memory that wasn't yet allocated. But they prevented: - implicit conversions between pointers and arrays - using bad pointers for output parameters in function calls - bad, implicit, conversions between numeric types - implicit conversions between enumerated values and integers - using non-existent enumerated values - strings with missing terminator - Using assignment operator when a comparison was intended - Doing pointer manipulation all over the place instead of when it is really needed For your m * n example, that is something you can easily do in Ada, even if a bit verbose. Hence why Rust would be less needed, because we would be in a computing world, where the majority of the exploits C has brought into mainstream computing would be reduced to a very tiny subset, also with unsafe red signs that one has to explicitly opt-in. And just like with Assembly we could probably manage it, if served in very tiny doses as infrastructure code for other languages. As for tagged architectures, why not? Specially since that is what Intel and other manufactures are now trying to push as a workaround tame C corruption errors. But all of that is history now, and we really do need languages like Rust to make the lower layers of our OSes and language runtimes safe.
- catnaroek 11y ago
  > And, yes they did not prevent the programmer of doing a double free or calling free in memory that wasn't yet allocated. Well, in 2016, or even in 1995, dynamic resource (not just memory!) allocation is the norm, not the exception, so, effectively, “unsafe dynamic resource management” means “unsafe” without further qualification. > (long list) These are indeed problems with C. Let's not beat a dead horse. > For your m * n example, that is something you can easily do in Ada, even if a bit verbose. Rather than “m * n”, it's more like “m + n”, or even “mx + ny”, or even “mx + padding + ny”, but okay. > Hence why Rust would be less needed, because we would be in a computing world, where the majority of the exploits C has brought into mainstream computing would be reduced to a very tiny subset, also with unsafe red signs that one has to explicitly opt-in. I would accept this claim if unsafe code would only be used to implement the occasional non-critical system component. But, can you implement a safe language runtime without “opt-in” unsafe language features? Clearly, static checks at some level are the only way of you really want safety. If you don't, that's okay - just be honest about it. > As for tagged architectures, why not? Because it's expensive! The user shouldn't have to use his machine to compute something that any responsible programmer would've known in advance. And runtime is too late to fix any mistakes anyway. > Specially since that is what Intel and other manufactures are now trying to push as a workaround tame C corruption errors. Well, that's sad.

derefr 11y ago

It might be desirable now, but those '60s/'70s OSes probably weren't dynamically allocating memory ever. They'd make a buffer in [their equivalent to] the .BSS section that was M×sizeof(int), and another that was N×sizeof(float), and then they'd process records through those buffers blockwise.

pcwalton 11y ago
Exactly. In the '60s and '70s malloc was a luxury that most programs didn't have, and so Rust's facilities weren't needed to ensure safety. That doesn't describe the state of play in 2016. Those safer languages from the '60s and '70s would also be inadequate to ensure safety today.
catnaroek 11y ago
> It might be desirable now, but those '60s/'70s OSes probably weren't dynamically allocating memory ever. Those systems suddenly seem a lot less impressive now. While the lack of dynamic resource management poses other problems (e.g. determining up-front if the system has enough resources to complete the given task), I can't imagine this being more challenging than implementing a modern runtime system (JIT compiler, garbage collector, green thread scheduler, etc.).

pjmlp 11y ago

Some of the languages that come to mind without GC, Algol and its variants, NEWP, Mesa, Modula-2, Ada. With GC, Lisp, Smalltalk, Modula-2+, Modula-3, Eiffel, Oberon, Oberon-2, Active Oberon, Component Pascal,.... Keeping the focus on the ones without GC, all of them were use to build full stack mainframes, so of course they supported dynamic structures. Just the memory was measured in KB not GB. And, yes they did not prevent the programmer of doing a double free or calling free in memory that wasn't yet allocated. But they prevented: - implicit conversions between pointers and arrays - using bad pointers for output parameters in function calls - bad, implicit, conversions between numeric types - implicit conversions between enumerated values and integers - using non-existent enumerated values - strings with missing terminator - Using assignment operator when a comparison was intended - Doing pointer manipulation all over the place instead of when it is really needed For your m * n example, that is something you can easily do in Ada, even if a bit verbose. Hence why Rust would be less needed, because we would be in a computing world, where the majority of the exploits C has brought into mainstream computing would be reduced to a very tiny subset, also with unsafe red signs that one has to explicitly opt-in. And just like with Assembly we could probably manage it, if served in very tiny doses as infrastructure code for other languages. As for tagged architectures, why not? Specially since that is what Intel and other manufactures are now trying to push as a workaround tame C corruption errors. But all of that is history now, and we really do need languages like Rust to make the lower layers of our OSes and language runtimes safe.

catnaroek 11y ago
> And, yes they did not prevent the programmer of doing a double free or calling free in memory that wasn't yet allocated. Well, in 2016, or even in 1995, dynamic resource (not just memory!) allocation is the norm, not the exception, so, effectively, “unsafe dynamic resource management” means “unsafe” without further qualification. > (long list) These are indeed problems with C. Let's not beat a dead horse. > For your m * n example, that is something you can easily do in Ada, even if a bit verbose. Rather than “m * n”, it's more like “m + n”, or even “mx + ny”, or even “mx + padding + ny”, but okay. > Hence why Rust would be less needed, because we would be in a computing world, where the majority of the exploits C has brought into mainstream computing would be reduced to a very tiny subset, also with unsafe red signs that one has to explicitly opt-in. I would accept this claim if unsafe code would only be used to implement the occasional non-critical system component. But, can you implement a safe language runtime without “opt-in” unsafe language features? Clearly, static checks at some level are the only way of you really want safety. If you don't, that's okay - just be honest about it. > As for tagged architectures, why not? Because it's expensive! The user shouldn't have to use his machine to compute something that any responsible programmer would've known in advance. And runtime is too late to fix any mistakes anyway. > Specially since that is what Intel and other manufactures are now trying to push as a workaround tame C corruption errors. Well, that's sad.