6 ms·

What's somewhat interesting is memory safety is not a totally new concept. I wonder if memory safety had mattered more, whether other languages might have caug

What's somewhat interesting is memory safety is not a totally new concept. I wonder if memory safety had mattered more, whether other languages might have caught on a bit more, developed more etc. Rust is the new kid, but memory safety in a language is not a totally new concept. The iphone has gone down the memory unsafe path including for high sensitivity services like messaging (2007+). They have enough $ to re-write some of that if they had cared to, but they haven't. Weren't older language like Ada or Erlang memory safe way back?

dagmx 5y ago
AFAIK the issue with messaging isn't that the core app itself is written in an unsafe language , but that many components it interacts with are unsafe. E.g file format parsers using standard libraries to do it. Granted those should also be rewritten in safer languages but often they're massive undertakings
xiphias2 5y ago
Memory safe language that can compete with C/C++ in performance and resource usage is a new concept. AFAIK ADA guarantees memory safety only if you statically allocate memory, and other languages have GC overhead. Rust is really something new.
- openasocket 5y ago
  There's different classes of memory un-safety: buffer overflow, use after free, and double free being the main ones. We haven't seen a mainstream language capable of preventing use and free and double free without GC overhead until Rust. And that's because figuring out when an object is genuinely not in use anymore, at compile time, is a really hard problem. But a buffer overflow like from the article? That's just a matter of saving the length of the array alongside the pointer and doing a bounds check, which a compiler could easily insert if your language had a native array type. Pascal and its descendants have been doing that for decades.
  - slownews45 5y ago
    The trick is not that the language support a safe approach (C++ has smart pointers / "safe" code in various libraries) in my view but simply that you CAN'T cause a problem even being an idiot. This is where the GC languages did OK.
  - shakna 5y ago
    > That's just a matter of saving the length of the array alongside the pointer and doing a bounds check, which a compiler could easily insert if your language had a native array type. Pascal and its descendants have been doing that for decades. GCC has also had an optional bounds checking branch since 1995. [0] GCC and Clang's sanitisation switches also support bounds checking, for the main branches, today, unless the sanitiser can't trace the origin or you're doing double-pointer arithmetic or further away from the source. AddressSanitizer is also used by both Chrome & Firefox, and failed to catch this very simple buffer overflow from the article. It would have caught the bug, if the objects created were actually used and not just discarded by the testsuite. [0] https://gcc.gnu.org/extensions.html https://gcc.gnu.org/extensions.html
    - avar 5y ago
      > It would have caught the bug, if the objects created were actually used and not just discarded by the testsuite. They were only testing with AddressSanitizer, not running the built binaries with it? Doing so is slow to say the least, but you can run programs normally with these runtime assertions. It even has the added benefit of serving as a nice emulator for a much slower system.
  - senderista 5y ago
    > We haven't seen a mainstream language capable of preventing use and free and double free without GC overhead until Rust. Sorry, that just isn’t the case. It is simple to design an allocator that can detect any double-free (by maintaining allocation metadata and checking it on free), and prevent any use-after-free (by just zeroing out the freed memory). (Doing so efficiently is another matter.) It’s not a language or GC issue at all.
- pjmlp 5y ago
  There were OSe written in memory safe languages before two persons decided to create a toy OS in Assembly for their toy PDP-7.
- pjmlp 5y ago
  What new concept? When C and C++ appeared they were hardly usefull for game development, hence why most games were coded in Assembly. After C, alongside TP, got a spot on languages accepted for game development, it took about 5 years for C++ to join that spot, mostly triggered by Watcom C++ on the PC, and PS2 SDK. There was no GC overhead on the systems programming being done in JOVIAL, NEWP, PL/I,...
IshKebab 5y ago
The issue isn't really that there was a shortage of memory safe languages, it's that there was a shortage of memory safe languages that you can easily use from C/C++ programs. Nobody is going to ship a JVM with their project just so they can have the "fun" experience of using Java FFI to do crypto. Realistically Rust is still the only memory safe language that you could use, so it's not especially surprising that nobody did it 18 years ago.
- FartyMcFarter 5y ago
  > The issue isn't really that there was a shortage of memory safe languages, it's that there was a shortage of memory safe languages that you can easily use from C/C++ programs. Just as importantly, there was also a shortage of memory safe languages that had good performance.

dagmx 5y ago

AFAIK the issue with messaging isn't that the core app itself is written in an unsafe language , but that many components it interacts with are unsafe. E.g file format parsers using standard libraries to do it. Granted those should also be rewritten in safer languages but often they're massive undertakings

xiphias2 5y ago

Memory safe language that can compete with C/C++ in performance and resource usage is a new concept. AFAIK ADA guarantees memory safety only if you statically allocate memory, and other languages have GC overhead. Rust is really something new.

openasocket 5y ago
There's different classes of memory un-safety: buffer overflow, use after free, and double free being the main ones. We haven't seen a mainstream language capable of preventing use and free and double free without GC overhead until Rust. And that's because figuring out when an object is genuinely not in use anymore, at compile time, is a really hard problem. But a buffer overflow like from the article? That's just a matter of saving the length of the array alongside the pointer and doing a bounds check, which a compiler could easily insert if your language had a native array type. Pascal and its descendants have been doing that for decades.
- slownews45 5y ago
  The trick is not that the language support a safe approach (C++ has smart pointers / "safe" code in various libraries) in my view but simply that you CAN'T cause a problem even being an idiot. This is where the GC languages did OK.
- shakna 5y ago
  > That's just a matter of saving the length of the array alongside the pointer and doing a bounds check, which a compiler could easily insert if your language had a native array type. Pascal and its descendants have been doing that for decades. GCC has also had an optional bounds checking branch since 1995. [0] GCC and Clang's sanitisation switches also support bounds checking, for the main branches, today, unless the sanitiser can't trace the origin or you're doing double-pointer arithmetic or further away from the source. AddressSanitizer is also used by both Chrome & Firefox, and failed to catch this very simple buffer overflow from the article. It would have caught the bug, if the objects created were actually used and not just discarded by the testsuite. [0] https://gcc.gnu.org/extensions.html https://gcc.gnu.org/extensions.html
  - avar 5y ago
    > It would have caught the bug, if the objects created were actually used and not just discarded by the testsuite. They were only testing with AddressSanitizer, not running the built binaries with it? Doing so is slow to say the least, but you can run programs normally with these runtime assertions. It even has the added benefit of serving as a nice emulator for a much slower system.
- senderista 5y ago
  > We haven't seen a mainstream language capable of preventing use and free and double free without GC overhead until Rust. Sorry, that just isn’t the case. It is simple to design an allocator that can detect any double-free (by maintaining allocation metadata and checking it on free), and prevent any use-after-free (by just zeroing out the freed memory). (Doing so efficiently is another matter.) It’s not a language or GC issue at all.
pjmlp 5y ago
There were OSe written in memory safe languages before two persons decided to create a toy OS in Assembly for their toy PDP-7.
pjmlp 5y ago
What new concept? When C and C++ appeared they were hardly usefull for game development, hence why most games were coded in Assembly. After C, alongside TP, got a spot on languages accepted for game development, it took about 5 years for C++ to join that spot, mostly triggered by Watcom C++ on the PC, and PS2 SDK. There was no GC overhead on the systems programming being done in JOVIAL, NEWP, PL/I,...

IshKebab 5y ago

The issue isn't really that there was a shortage of memory safe languages, it's that there was a shortage of memory safe languages that you can easily use from C/C++ programs. Nobody is going to ship a JVM with their project just so they can have the "fun" experience of using Java FFI to do crypto. Realistically Rust is still the only memory safe language that you could use, so it's not especially surprising that nobody did it 18 years ago.

FartyMcFarter 5y ago
> The issue isn't really that there was a shortage of memory safe languages, it's that there was a shortage of memory safe languages that you can easily use from C/C++ programs. Just as importantly, there was also a shortage of memory safe languages that had good performance.