Did any of those provide safety by means of compile-time checks (as opposed to sophisticated runtime systems, which are by necessity more expensive), though? AFAICT, Lisp didn't, Smalltalk didn't and Oberon didn't.
For example, the NEWP in MCP only allowed unsafe code in modes where the system administrator would configure them as such, back in 1961.
Also, determining whether code is safe to run requires proof, not trust. Since when are system administrators particularly skilled at coming up with proofs?
Also the type of enabling/disabling unsafe code in those lanugages was not much different than running "rustc -D unsafe-code"
Also computer admins in the 60's were programmers.
Many of memory corruption issues with C aren't a problem with the stronger type system of Algol and PL/* family of languages.
However OSes written in those languages were commercial, whereas C was bundled with UNIX, distributed for free, because AT&T was forbidden to charge for it.
If it wasn't for that, most likely Rust wouldn't be needed, at least not in the way it looks like.
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.
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.).
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.
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.
No, because at systems programming level, specially when interfacing with hardware is not possible to have 100% safety.
Not even SPARK or formal methods allow for that, there is always a very tiny portion of unsafety at some level.
But the point is not to remove it completely, rather to contain it to the point that is a tractable problem and easy to review, even manually.
Which is easier to achieve when languages are strong typed and require explicit escape hatches for doing unsafe things.
> 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.
Expensive is relative. I rather have the computer do stuff for me, and focus being productive.
Also just like everything else in computing, if there would be more research in that area, most likely the performance would increase.
Given that the manufacturers are turning to tagged architectures ideas to try to sort out the C mess, apparently they see a path forward there.
> > 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.
Intel has added the MPX extensions to their processors, already available in gcc, clang and msvc++
https://software.intel.com/en-us/articles/introduction-to-in...
There is the new CHERI processor being developed at Cambridge exactly with the purpose of a tagged processor for C code
No disagreement here. What I'm saying is that, in today's environment, requiring escape hatches for dynamic resource management is effectively requiring escape hatches for everything. The worst part is that, in most languages, you don't even need to enable escape hatches to preform nonsensical operations like mutating the same object in two threads, without explicit concurrency control. Literally everything is unsafe!
To the best of my knowledge, the only practical language today that attempts to mitigate these issues is Rust. Even if we somehow revived those old "safer than C even if this doesn't mean much" languages, they would probably not help much.
> Expensive is relative. I rather have the computer do stuff for me, and focus being productive.
With runtime checks, your computer isn't really doing anything for you. Your user's computer is alleviating a problem created by you.
Besides we have to make those CPU quadcores with 8 threads and a 4 GPU cores busy with something.
Also, as much as I like Rust, they still need to sort out some usability issues like non-lexical ownership.
I'd rather take the inconvenience of declaring the occasional use-once temporary variable, which takes at most 10 seconds of my time, than the inconvenience of tracking object lifetime bugs, which can take days or weeks to fix. Correctness is non-negotiable.
http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr...
Then, you can go from there in your language or compiler design.
The runtime check doesn't make the operation any less unsafe - it only makes the consequences of an error less disastrous.
I think we have a different definition of unsafe. If you think it's potential to cause problems, then I agree it doesn't make it less unsafe. Alternatively, it does make it less unsafe if that means it reduces the ability to invisibly corrupt data, hack your system, or crash your system. That's what I'm claiming. Even Rust or Ada might have a hard time meeting that definition once their pristine codes are converted into assembly.
“Potentially without useful meaning”, e.g., indexing an array without knowing whether the the index is within bounds.
> Alternatively, it does make it less unsafe if that means it reduces the ability to invisibly corrupt data, hack your system, or crash your system.
Your kid (your data) attends the same school as a bully (your program). One day, the bully threatens to punch your kid in the face (raises an exception). “But it's less wrong because he never punched your kid! He only threatened it!”
> Even Rust or Ada might have a hard time meeting that definition once their pristine codes are converted into assembly.
As long as the assembly code has the same meaning as the safe program from which it was generated, it's safe.
You're going out on a limb here. I'm not even countering that example as it's rigged to prevent that. Instead, I'll point out these unsafe things don't happen in a vacuum: there's something in the language that sets the risk in motion and then there's something else that determines what happens. The compile-time safety stops it from being set in motion. The run-time safety makes things set in motion meaningless as they'll just be exceptions or alerts for admins.
Back to your analogy, it would be more like a prison learning environment where people learned in cells with bulletproof glass while one shouted he was "gonna cut someone" for not sharing answers. He can try every unsafe thing he wants but the glass makes it meaningless. The prisoner that's being targeted can literally just pretend all that unsafety doesn't even exist with no effect.
Ideally, we have prevention and detection. Reason for prevention is obvious. Reason for detection, even in a perfect language scheme, is because compiler or hardware errors (esp SEU's) will make something act badly eventually with runtime measures being last-ditch effort. If there going to be there, though, then might as well lean on them some more if there's no performance hit, eh? ;)
Now, almost every hack on a system that I can think of requires forcing a pointer to go out-of-bounds or something like that. Further, the rest send in data that becomes code. One check, from Burroughs, is CPU looking for code tag bit before executing which only can be set by OS or isolated service on microkernel. So, that wouldn't work.
What remains, with little performance hit & no static checking, is a system where hackers (a) have to con the admin into installing malware, (b) break the minimal, trusted loader/installer w/out abusing above components, or (c) get a denial of service attack. Forget analogies: the reality is much more impressive given there's almost no high-severity CVE's left. You can also do great static checks and such as I always recommend. Yet, you either don't or rarely need them in practice if goal is integrity or confidentiality rather than availability.
"Check and incidentally... mate" (Sherlock Holmes, Game of Shadows)
My goal is correctness. A program that fails with a runtime exception is just as wrong as another that silently corrupts your data. Dijkstra put it very nicely:
“We could, for instance, begin with cleaning up our language by no longer calling a bug a bug but by calling it an error. (...) The nice thing of this simple change of vocabulary is that it has such a profound effect: while, before, a program with only one bug used to be "almost correct", afterwards a program with an error is just "wrong" (because in error).”
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/E...
Darn, Dijkstra or not, you still need some kind of runtime checks and protection for correctness. :)
[1] http://www.rockwellcollins.com/~/media/Files/Unsecure/Produc...
C and UNIX got widely adopted, because AT&T wasn't allowed to sell it, so they gave the source code for free to universities. Which then used the code to replace the expensive OSes that they were running on their mainframes.
When AT&T was allowed to charge for it afterwards, they tried to make people pay for it, but failed to do so.
Also around this time UNIX vendors started selling the developer tools separately instead of having them for free. This motivated many to contribute to GNU, which was largely ignored up to that point.
https://news.ycombinator.com/item?id=11621318
So, it wasn't the money for once.
Have their programmers manual on my reading list.
But got the idea it is a very niche market, even smaller than IBM mainframes.
https://en.wikipedia.org/wiki/Unisys
"In September 1986 Unisys was formed through the merger of the mainframe corporations Sperry and Burroughs, with Burroughs buying Sperry for $4.8 billion. "
"The merger was the largest in the computer industry at the time and made Unisys the second largest computer company with annual revenue of $10.5 billion"
As to why IBM dominated, I have a hypothesis that's consistent with what happened to other companies. It's basically Gabriel's Worse is Better effect where certain characteristics improve marketing & uptake. The IBM mainframe, IIRC, were backward compatible or integrated with stuff IBM people already bought. They were optimized for Fortran etc that existing apps were written in where Burroughs was optimized for Algol, the language of the future. Further, in a trend that still exists, people focused on raw performance per dollar instead of reliability, maintenance, security, technical debt reduction, and so on that Burroughs architecture could provide. Similar effect with Intel i432, i960, and later Itanium w/ its excellent reliability/security improvements. Burroughs started taking out hardware security & recently got ported to Intel CPU's IIRC. Intel just stopped taking chances. Both in legacy mode since it's all people buy.
Sad story of how computer market works. The Burroughs systems are still around, though, with Unisys making plenty of money. MCP is on release 17 with Unisys also releasing a tool that lets you run MCP in a virtual machine on a PC. It's called MCPExpress I believe. Here's the page.
http://www.unisys.com/offerings/high-end-servers/clearpath-f...
So in a way, Rust has already succeeded.