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.

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.

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

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.

Replying to

right, i think i accidentally inched my internal model closer to "strict C VM" (Sulong comes to mind) than to "Valgrind memcheck, but in your compiler", but that's indeed not really feasible if you're mixing with code that doesn't run under it

Replying to

that said, my intention was to describe Nim's unsafety in terms of the C primitives it uses—it certainly seems to permit use-after-free of stack references (nim-lang.org/docs/manual.ht), and pointer arithmetic (although rarely used), presumably w/o bounds safety