That is why i keep mentioning Ada in the hope to balance the "Memory Safe language" selection bias.
I only mention it a few times whenever the topic of memory safe language and Rust came up. And I have already been asked to stop.
I only mention it a few times whenever the topic of memory safe language and Rust came up. And I have already been asked to stop.
Don't worry about it.
It's important to bring it up because there's quite a few people who don't want to adopt Rust for one reason or another, but want a mature lower level language alternative to what they're using now.
I try to mention Ada when people are looking for something with its characteristics, but don't appear to have considered it. I try not to hijack threads or interject, be rude or overbearing, though it has probably read that way at least once.
> That is why i keep mentioning Ada in the hope to balance the "Memory Safe language" selection bias.
Ada suffers from a lack of proper marketing and being misunderstood. The Ariane 5 disaster gets mentioned as reason to not use it, but not Ariane 5's track record since as of the most reliable payload rockets in history (including a streak of 80+ successive launches), and because of this was picked to launch the James Webb Space Telescope. Ada's usually mentioned along with COBOL or Modula-2, so I expected a bloated bureaucratic grotesque language, not a modern one with decent tooling and a package manager. While it may have been "complicated" when released, the newer versions, especially Ada 2012 have really polished up the language well.
I've been productive in it since the early months of using it, and it has exceeded most of my expectations.
One is the naive one, someone that lacks the proper background and for whatever reasons thinks it is the only way, thus Rust.
Then we have those that are aware, but think all the other safety approaches are not valid for whatever reason, thus Rust.
Then we have those that kind of feel threatened by the security awareness that Rust brings into the picture, so whenever we talk about security, there is pavlovian reaction that it must be Rust when the subject is security.
Picking any language that embraces bounds checking enabled by default, and proper string/arrays, is already a major improvement.
Even bog standard C can be made safe, and include bounds checking if you create and consistently use an API that supports that mindset - see for e.g. Microsoft's string safe lib (not that I'm saying that is the epitome of such a thing).
However the will and the effort has to be there, C is an incredibly flexible and capable language and can be as safe as you want it to be.
The last Random ascii article I read, he found an easily exploitable buffer overflow in iOS simply by checking the code to see where it used memmove and worked out the exploit from there, guessing correctly that there was no bounds checking. So it seems that the usual culprits are fairly easy to spot, but somebody needs to replace the worst APIs with something safer (memmove, memcpy, memset, malloc, a = b).
Microsoft does it, because it comes along with SAL[0], which is kind of Microsoft's own Frama-C.
Also as long as WG14 doesn't care, everyone will keep passing char* around while hoping it is actually null terminated and points to the right place in memory.
Technically, ISO C could get safer types, or have something like SAL/FORTIFY, but as you say, without will it will never happen.
[0] - https://docs.microsoft.com/en-us/cpp/code-quality/using-sal-...