6 ms·

The fact that re-using a slot for a different object of the same type is considered a memory safety technique is ridiculous.

obl 2y ago
It is not ridiculous at all. Those things have pretty precise definitions and type segregation absolutely does remove a bunch of soundness issues related to type confusion. You can think of it as the rather classic "Vec of struct + numeric IDs" that is used a lot e.g. in Rust to represent complex graph-like structures. This combined with bound checking is absolutely memory safe. It has a bunch of correctness issue that can arise due to index confusion but those are not safety issues. When combined with some kind of generational counters those correctness issue also go away but are only caught at runtime not at compile time (and they incur a runtime cost). Rust's memory safety is about avoiding liveness issues (that become type confusions since all memory allocators will reuse memory for different types), nothing more, nothing less.
- jandrewrogers 2y ago
  FWIW, arrays of structs + integer handles is the primary way objects are represented in performance-engineered C++.
- gpderetta 2y ago
  > but those are not safety issues. there are not memory safety issues. But they definitely can lead to security issues with some sort of confused deputy attack. For example a capability based system that relied on just this form of memory safety would be pointless. Of course this can be mitigated by adding version counters to objects and object selectors.
adamrezich 2y ago
“Safety” is a very overloaded English word with strong connotations, and the popularization of it in the context of “memory safety” has been good in some ways, but has really poisoned the discourse in many others.
AlotOfReading 2y ago
It absolutely is. Some embedded mallocs do this under the hood against a predefined linker table. Genuinely helps even with the restrictions it imposes.
eddd-ddde 2y ago
Are you implying that it is unsafe? Or that it is unrelated to safety properties?
- mgaunard 2y ago
  It just shows memory safety is a joke, simply replacing a class of bugs with another.
  - IshKebab 2y ago
    It isn't a joke. With memory safety bugs the value of an object can unexpectedly be any bit pattern. That breaks the assumptions of basically every language and leads to pretty much anything happening. If you have an array of objects of the same type and you just pick the wrong one, then the data still has to be a valid bit pattern. Yes it might still be a security bug, but it's much less likely because you aren't completely subverting the language. Surely you don't think all bugs are the same because they are all bugs?
    - mgaunard 2y ago
      It takes a lot more for a program to be correct than having valid bit patterns. To begin with, the whole point of classes is to maintain invariants. Guaranteeing that a location in memory matches the valid bit patterns of its members is far from sufficient.
      - IshKebab 2y ago
        > It takes a lot more for a program to be correct than having valid bit patterns. Obviously. I never said otherwise. What's your point?
ptx 2y ago
Maybe we need to introduce the term "value safety" to complement "type safety". If a language is merely type-safe, then it might be OK to silently replace a value with a different one of the same type, sure, fine. Who cares if the program transmits the wrong message to the wrong recipient as long as it's definitely some message and some recipient? But a value-safe language, I suggest, is one that doesn't pull this kind of switcheroo.
jcarrano 2y ago
Reminds me of a video I saw about "cloning" on Super Mario 64[1]. SM64 uses slots and one can mess around with slot deletions to get random objects. [1] https://www.youtube.com/watch?v=X2AhyDI58-I https://www.youtube.com/watch?v=X2AhyDI58-I

obl 2y ago

It is not ridiculous at all. Those things have pretty precise definitions and type segregation absolutely does remove a bunch of soundness issues related to type confusion. You can think of it as the rather classic "Vec of struct + numeric IDs" that is used a lot e.g. in Rust to represent complex graph-like structures. This combined with bound checking is absolutely memory safe. It has a bunch of correctness issue that can arise due to index confusion but those are not safety issues. When combined with some kind of generational counters those correctness issue also go away but are only caught at runtime not at compile time (and they incur a runtime cost). Rust's memory safety is about avoiding liveness issues (that become type confusions since all memory allocators will reuse memory for different types), nothing more, nothing less.

jandrewrogers 2y ago
FWIW, arrays of structs + integer handles is the primary way objects are represented in performance-engineered C++.
gpderetta 2y ago
> but those are not safety issues. there are not memory safety issues. But they definitely can lead to security issues with some sort of confused deputy attack. For example a capability based system that relied on just this form of memory safety would be pointless. Of course this can be mitigated by adding version counters to objects and object selectors.

adamrezich 2y ago

“Safety” is a very overloaded English word with strong connotations, and the popularization of it in the context of “memory safety” has been good in some ways, but has really poisoned the discourse in many others.

AlotOfReading 2y ago

It absolutely is. Some embedded mallocs do this under the hood against a predefined linker table. Genuinely helps even with the restrictions it imposes.

eddd-ddde 2y ago

Are you implying that it is unsafe? Or that it is unrelated to safety properties?

mgaunard 2y ago
It just shows memory safety is a joke, simply replacing a class of bugs with another.
- IshKebab 2y ago
  It isn't a joke. With memory safety bugs the value of an object can unexpectedly be any bit pattern. That breaks the assumptions of basically every language and leads to pretty much anything happening. If you have an array of objects of the same type and you just pick the wrong one, then the data still has to be a valid bit pattern. Yes it might still be a security bug, but it's much less likely because you aren't completely subverting the language. Surely you don't think all bugs are the same because they are all bugs?
  - mgaunard 2y ago
    It takes a lot more for a program to be correct than having valid bit patterns. To begin with, the whole point of classes is to maintain invariants. Guaranteeing that a location in memory matches the valid bit patterns of its members is far from sufficient.
    - IshKebab 2y ago
      > It takes a lot more for a program to be correct than having valid bit patterns. Obviously. I never said otherwise. What's your point?

ptx 2y ago

Maybe we need to introduce the term "value safety" to complement "type safety". If a language is merely type-safe, then it might be OK to silently replace a value with a different one of the same type, sure, fine. Who cares if the program transmits the wrong message to the wrong recipient as long as it's definitely some message and some recipient? But a value-safe language, I suggest, is one that doesn't pull this kind of switcheroo.

jcarrano 2y ago

Reminds me of a video I saw about "cloning" on Super Mario 64[1]. SM64 uses slots and one can mess around with slot deletions to get random objects. [1] https://www.youtube.com/watch?v=X2AhyDI58-I https://www.youtube.com/watch?v=X2AhyDI58-I