6 ms·

I don’t understand your point and you’re wrong on a couple of things. > C code that reads uninitialized data is presumed to be buggy, because it wouldn't be do

I don’t understand your point and you’re wrong on a couple of things. > C code that reads uninitialized data is presumed to be buggy, because it wouldn't be doing that unless it thought the memory was initialized. But the read itself is not unsafe. Rust is just confused, and is preventing all reads from uninitialized data a-priori instead of relying on its perfectly working type system to tell it whether the uninitialized data is safe to use Reads of uninitialized memory is unsafe full stop. That’s literally what Rust’s memory safety is about. If you give that up you’re not in safe land and you can always use unsafe & all the risks that come with that to try to write more optimal code / abstractions. This article is literally about the mechanisms Rust is trying to stabilize how you use the type system to go from a block of uninitialized memory & is aware of writes occuring so that it can take a &[MaybeUninit<T>] and give you back a &[T] after a call to read which wrote into the slice. But reading uninitialized memory by definition is tautologically unsafe. It doesn’t mean that the computer will pull out a knife and kill you, but it does mean you’re no longer memory safe.

lmm 2y ago
> Reads of uninitialized memory is unsafe full stop. That’s literally what Rust’s memory safety is about. If you give that up you’re not in safe land and you can always use unsafe & all the risks that come with that to try to write more optimal code / abstractions. Reading uninitialized (but correctly owned) memory is not inherently unsafe. It has strange (and mostly useless) semantics, but it's not a safety issue. E.g. something like the OpenSSL key generation that Debian broke - [uninitialised buffer] ^= [generated random values] - is safe, and afterwards you can read from that buffer and get (safe, real, stable) values.
- vlovich123 2y ago
  I’m not sure what point you’re arguing. C and C++ treat uninitialized reads as UB, full stop. Any C/C++ compiler can do whatever it wants if it realizes that’s the case. Rust is no different, it’s just that it makes it a compile error in “safe” mode and forces you to annotate it with unsafe to be explicit it’s intentional (while still following the rules mind you - accessing uninitialized memory is still UB even in unsafe rust and doing so gives the compiler freedom to break your code)
  - lmm 2y ago
    > C and C++ treat uninitialized reads as UB, full stop. Not true; if it's an object that has its address taken, of a type that does not have a trap representation, then reading it results in an unspecified value and is not UB. Which aligns with what one might naively expect to happen.
    - vlovich123 2y ago
      This is true of Rust as well since it has a very similar memory model. You just have to explicitly tell the compiler you know what you’re doing in Rust through the unsafe keyword.
      - lmm 2y ago
        So reading an uninitialised u8 is not UB? I found the Rust documentation pretty unclear, u8 does not have a "restricted set of valid values" which suggests it should be ok, but the documentation also says "the only cases in which reading uninitialized memory is permitted are inside unions and in “padding” (the gaps between the fields of a type)".

lmm 2y ago

> Reads of uninitialized memory is unsafe full stop. That’s literally what Rust’s memory safety is about. If you give that up you’re not in safe land and you can always use unsafe & all the risks that come with that to try to write more optimal code / abstractions. Reading uninitialized (but correctly owned) memory is not inherently unsafe. It has strange (and mostly useless) semantics, but it's not a safety issue. E.g. something like the OpenSSL key generation that Debian broke - [uninitialised buffer] ^= [generated random values] - is safe, and afterwards you can read from that buffer and get (safe, real, stable) values.

vlovich123 2y ago
I’m not sure what point you’re arguing. C and C++ treat uninitialized reads as UB, full stop. Any C/C++ compiler can do whatever it wants if it realizes that’s the case. Rust is no different, it’s just that it makes it a compile error in “safe” mode and forces you to annotate it with unsafe to be explicit it’s intentional (while still following the rules mind you - accessing uninitialized memory is still UB even in unsafe rust and doing so gives the compiler freedom to break your code)
- lmm 2y ago
  > C and C++ treat uninitialized reads as UB, full stop. Not true; if it's an object that has its address taken, of a type that does not have a trap representation, then reading it results in an unspecified value and is not UB. Which aligns with what one might naively expect to happen.
  - vlovich123 2y ago
    This is true of Rust as well since it has a very similar memory model. You just have to explicitly tell the compiler you know what you’re doing in Rust through the unsafe keyword.
    - lmm 2y ago
      So reading an uninitialised u8 is not UB? I found the Rust documentation pretty unclear, u8 does not have a "restricted set of valid values" which suggests it should be ok, but the documentation also says "the only cases in which reading uninitialized memory is permitted are inside unions and in “padding” (the gaps between the fields of a type)".