Fix uninitialized memory exposure in IO reads

[matteoldani]

This PR addresses an API soundness bug where uninitialized heap memory could be exposed to safe io::Read implementations.

Currently, both ReadExt::read_to_tendril and TendrilSink::read_from expand their internal buffers via push_uninitialized() before passing the resulting slice to a generic io::Read trait object. As noted by an existing FIXME comment in the codebase:

  │  // FIXME: this exposes uninitialized bytes to a generic R type
  │  // this is fine for R=File which never reads these bytes,
  │  // but user-defined types might.

While standard readers like std::fs::File only write to the buffer, a poorly written or unconventional custom io::Read implementation might attempt to read from the provided slice. Because these tendril functions are safe to call, exposing
uninitialized memory this way technically violates Rust's strict memory safety guarantees and triggers Undefined Behavior under Miri.

Changes:

• Following the precedent of the standard library (e.g., Vec ), this PR explicitly zero-initializes the newly appended buffer slice using std::ptr::write_bytes before passing it to the generic reader.
• Using write_bytes avoids the UB of creating safe Rust references ( &mut [u8] ) to uninitialized memory. It also compiles down directly to a highly optimized LLVM memset intrinsic, ensuring there is no meaningful performance regression.

Resolves #752

[simonwuelker]

Given that the buffer is not actually uninitialized anymore I think we should be able to get rid of the unsafe. This might require adding a new API, something akin to Vec::resize.

[matteoldani]

True.

I'll push a change that introduces push_zeros(n) that imho aligns with the overall tendril approach of "push_<>" rather then the absolute resize.

[matteoldani]

FYI: @simonwuelker this is the new API

[simonwuelker]

Two things that I forgot during the first review:

• We should only expose this for Tendril<fmt::Bytes, A>, not for all formats, as we might violate the internal invariants of the tendril otherwise.
• Let's pass the byte that should be written as an argument, that way the method is actually useful in a more general context. Maybe call the method extend?

Apologies for not thinking of this earlier :/

[matteoldani]

No worries, I will work on them tomorrow.

Regarding the API shape, I don't have a strong preference. As I mentioned in the previous comment I kept the "push" shape since it seemed more common in tendril API but happy to refactor it into an extend