It's not as painless as it could be though, because many of the MaybeUninit<T> -> T conversion fns are unstable. Eg the code in TFA needs `&mut [MaybeUninit<T>] -> &mut [T]` but `[T]::assume_init_mut()` is unstable. But reimplementing them is just a matter of copying the libstd impl, that in turn is usually just a straightforward reinterpret-cast one-liner.

    let mut data = Vec::with_capacity(sz);
    unsafe { data.set_len(sz) };
    buf.copy_to_slice(data.as_mut_slice());

There are two actual differences in this regard: C pointers are more ergonomic than Rust pointers. And Rust has an additional feature called references, which enable a lot more aggressive compiler optimizations, but which have the restriction that you can’t have a reference to uninitialized memory.

Something like:

  fn convert<'i, 'o>(inp: &'i [u8], buf: &'o mut MaybeUninit<u8>) -> &'o mut [u8]

Edit: it works: https://play.rust-lang.org/?version=stable&mode=debug&editio...

I would imagine there isn't that many cases where we are reading uninitalised memory and counting on that reading not saving a value. It would happen when reading in 8-byte blocks for alignment, but does it happen that much elsewhere?

it pretty much requires the compiler to initialize all values when they first "appear"

except that this is impossible and outright hazardous if pointers are involved

But doable for a small subset like e.g.

- stack values (but would inhibit optimizations, potentially pretty badly)

- some allocations e.g. I/O buffers, (except C alloc has no idea that you are allocating an I/O buffer)

Can you provide (on say x86_64) an example of this, other than the case where the compiler prunes cases based on characterizing certain paths as UB? In other words, a case where "an uninitialized value is well-defined but can be different on each read" allows more performance optimization than "the value will be the same on each read".

> Also, an uninitialized value might be in a memory page that gets reclaimed and then mapped in again, in which case (because it hasn’t been written to) the OS doesn’t guarantee it will have the same value the second time. There was recently a bug discovered in one of the few algorithms that uses uninitialized values, because of this effect.

This does not sound correct to me, at least for Linux (assuming one isn't directly requesting such behavior with madvise or something). Do you have more information?

but I guess this isn't just about I/O buffers ;)

Arguably, the existence of "asm!() freeze" has already broken this idea. Of course, you nominally don't get any guarantees about the stability of data that asm!() code reads from uninitialized bytes, yet you can do it nonetheless.

And it's not like it's practical to say "asm!() code is always unsound if it uses uninitialized bytes like they're numbers!", since lots of it does useful stuff like communicating with the kernel with structs that get serialized, and it can also open up interfaces like mmap() which translate possibly-uninitialized virtual-memory bytes into definite kernel bytes.

Not to mention /proc/self/mem and similar kernel-provided debugging utilities that can peek into memory as serialized data.

Some people--especially when those people are closest to the workings of the operational semantics--not being comfortable is a sign that it is in fact harder than it looks.

The problems with "freeze" are in the same vein as integer-to-pointer semantics: it's a change which turns out to have implications for things not closely related to the operation itself, giving it a spooky-action-at-a-distance effect that is hard to tame.

The deeper issue is that, while there is clearly a use for some sort of "garbage value" semantics in a high-level language (that supports things like uninitialized I/O buffers, excessive reads for vectorization, padding bytes within structures), it's not clear which of the subtly different variants of garbage value works the best for all of the use cases.

Safe abstractions for dealing with uninitialized memory efficiently are important in very niche scenarios to get optimal code out of the compiler and for reducing the ability to make a mistake when writing such code.

Reaching for C to do this is an emotional overreaction instead of calmly dealing with a small corner case that already has workarounds even if it does involve using unsafe

  $ cat bigbuf.c 

  #include <stdlib.h>
  #include <stdio.h>
  #include <string.h>

  #define DEFINITELY_BIG_ENOUGH 2U*1024*1024*1024
  int main(int nargs, char ** args)
  {

    char * definitely_big_enough = malloc(DEFINITELY_BIG_ENOUGH);

    if (nargs > 1)
    {
      memset(definitely_big_enough,0, DEFINITELY_BIG_ENOUGH);
    }

    sprintf(definitely_big_enough,"%s",args[0]);

    return 0;
  }
  
  $ /usr/bin/time ./bigbuf 
  0.00user 0.00system 0:00.00elapsed 100%CPU (0avgtext+0avgdata 1356maxresident)k
  0inputs+0outputs (0major+80minor)pagefaults 0swaps

  $ /usr/bin/time ./bigbuf 1 
  0.05user 1.25system 0:01.31elapsed 99%CPU (0avgtext+0avgdata 2098468maxresident)k
  0inputs+0outputs (0major+524369minor)pagefaults 0swaps

The closest thing to "conditionally returned to the kernel" is if the page had been given to madvise(MADV_FREE), but that would still not have the behavior they're talking about. Reading and writing would still produce the same content, either the original page content because the kernel hasn't released the page yet, or zero because the kernel has already released the page. Even if the order of operations is read -> kernel frees -> write, then that still doesn't match their story, because the read will produce the original page content, not zero.

That said, the code they're talking about is different from yours in that their code is specifically doing an out-of-bounds read. (They said "If you happen to allocate a string that's 128 bytes, and malloc happens to return an address to you that's 128 bytes away from the end of the page, you'll write the 128 bytes and the null terminator will be the first byte on the next page. So they're very clearly talking about the \0 being outside the allocation.)

So it is absolutely possible to have this setup: the string's allocation happens to be followed by a different allocation that is currently 0 -> the `data[size()] != '\0'` check is performed and succeeds -> `data` is returned to the caller -> whoever owns that following allocation writes a non-zero value to the first byte -> whoever called `c_str()` will now run off the end of the 128B string. This doesn't have anything to do with pages; it can happen within the bounds of a single page. It is also such an obvious out-of-bounds bug that it boggles my mind that it passed any sort of code review and required some sort of graybeard to point out.