> 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.
> 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.
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++
> Which is easier to achieve when languages are strong typed and require explicit escape hatches for doing unsafe things.
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.
> 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.
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.