Conversation

I disagree. We still haven't succeeded in making memory safety considered a base foundation. People are still making new languages that aren't memory safe, and they're getting popular.

Quote Tweet

edef

@edefic

Jul 24, 2021

memory safety is not a big deal in the same sense that not dying from the black plague is not a big deal—you're probably going to have a hard time producing great works if it's a problem left unsolved, but it's also mere foundation

Show this thread

146

Replying to

i can think of … Jonathan Blow's language (which doesn't seem of sufficient importance to bother remembering the name), and … Nim?

Replying to

and

i thought nim was “as safe as rust” (e.g. has some mechanism for restricting/explicitly annotating i safety)?

Tony "Abolish ICE" Arcieri

Replying to

and

I hesitate to even opine on this topic as it seems hotly debated and I don’t really know anything about Nim, but I’ve seen this mentioned in the past github.com/nim-lang/Nim/w

Replying to

and

that parses as "memory-safe in debug mode with sanitisers", which is on par with C/C++

Replying to

C and C++ can't be made memory safe with sanitizers. ASan only reliably detects linear overflows, not an arbitrary read/write from one object into another. A production implementation of even inter-object bounds safety for C is unavailable let alone temporal safety support.

Replying to

ASan relies on tracking which memory is in use with a shadow map representing chunks of memory with bits and has redzones around objects along with a quarantine for recently freed memory limited by how much memory you're willing to burn on it.

10:04 PM · Jul 25, 2021Twitter Web App

Replying to

It would be really cool if Clang had a switch to enforce memory safety but doing it efficiently and accurately likely requires having 128-bit or larger pointers which means having a different ABI. It could probably be done with ~30% performance overhead + fat ptr memory overhead.

Replying to

Also, it'd only really be inter-object bounds + temporal safety. It's impractical to do it intra-object because too much is permitted especially for memcpy, etc. Also still lots of holes and it'd require fixing a lot of UB / implementation-defined assumptions, etc. to use it.