* writes low bytes, discards high bytes
* panics if `nbytes` is greater than 8

Equivalent to

```
for _ in 0..cnt {
    self.put_u8(val);
}
```

but may work faster.

Name and signature is chosen to be consistent with `ptr::write_bytes`.

Include three specializations:
* `Vec<u8>`
* `&mut [u8]`
* `BytesMut`

`BytesMut` and `&mut [u8]` specializations use `ptr::write`, `Vec<u8>`
specialization uses `Vec::resize`.

Co-authored-by: Taiki Endo <[email protected]>

Rewrote the ledger in test_bytes_vec_alloc.rs to not piss off miri. The ledger is now a table within the allocator, which seems to satisfy miri. The old solution was to bundle an extra usize into the beginning of each allocation and then index past the start when deallocating data to get the size.

* Optimize `BytesMut::reserve`: Reuse vec if possible

If the `BytesMut` holds a unqiue reference to `KIND_ARC` while the
capacity of the `Vec` is not big enough , reuse the existing `Vec`
instead of allocating a new one.

Signed-off-by: Jiahao XU <[email protected]>

I find this diagram very helpful, but a little hard to distinguish
between the boxes and the lines that connect them. This commit redraws
the boxes with line drawing characters so that the boxes appear a
little more solid, and stand out from the other lines.

Previously, this code produced a &mut[u8] and a Box<[u8]> to the shared
allocation upon cloning it. If the underlying allocation were actually
shared, such as through a &[u8] from the Deref impl, creating either of
these types incorrectly asserted uniqueness of the allocation.

This fixes the example in #522, but Miri still does not pass on this
test suite with -Zmiri-tag-raw-pointers because Miri does not currently
understand int to pointer casts.

This reverts commit 89061c3.

Why am I even able to push to master?

This adds an unsafe method to convert a `&mut UninitSlice` into a
`&mut [MaybeUninit<u8>]`. This method is unsafe because some of the
bytes in the slice may be initialized, and the caller should not
overwrite them with uninitialized bytes.

This came about when auditing [tokio-util's udp frame], where they want
to pass the unitialized portion of a `BytesMut` to [ReadBuf::uninit].
They need to do this unsafe pointer casting in a few places, which
complicates audits. This method lets us document the safety invariants
the caller needs to maintain when doing this conversion.

[tokio-util's udp frame]: https://github.com/tokio-rs/tokio/blob/master/tokio-util/src/udp/frame.rs#L87
[ReadBuf::uninit]: https://docs.rs/tokio/latest/tokio/io/struct.ReadBuf.html#method.uninit

Signed-off-by: Jiahao XU <[email protected]>

Signed-off-by: Jiahao XU <[email protected]>
Co-authored-by: Alice Ryhl <[email protected]>

Signed-off-by: Jiahao XU <[email protected]>
Co-authored-by: Frank Steffahn <[email protected]>

Fixes calls to `reserve` when the underlying shared buffer was already
big enough to fit the requested capacity. Previously a new even larger
buffer was created anyways. This could eventually lead to an OOM
condition.

Fixes #549

Co-authored-by: Nicolae Mihalache <[email protected]>

When we freeze a BytesMut, we turn it into a Vec, and then convert that
to a Bytes.  Currently, this happen using Vec::into_boxed_slice, which
reallocates to a slice of the same length as the Vev if the length and
the capacity are not equal.  This can pose a performance problem if the
Vec is large or if this happens many times in a loop.

Instead, let's compare the length and capacity, and if they're the same,
continue to handle this using into_boxed_slice.  Otherwise, since we
have a type of vtable which can handle a separate capacity, the shared
vtable, let's turn our Vec into that kind of Bytes.  While this does not
avoid allocation altogether, it performs a fixed size allocation and
avoids any need to memcpy.

This function can be hot in applications that do a lot of encoding. Ideally would do the same for `<BytesMut as BufMut>::put_slice` and `<BytesMut as BufMut::put_u8`.

Introduce UninitSlice::from_slice and UninitSlice::from_uninit_slice
methods which safely create Uninit slice from provided slice of maybe
uninitialised or initialised memory.

In addition, add `From<&mut [T]>` implementations (for `T=u8` and
`T=MaybeUninit<u8>`) which do conversion from slice to UninitSlice.

Closes: #552

tokio::io::ReadBuf uses names `new` and `uninit` for its constructors.
For consistency with that, rename recently introduced UninitSlice
constructors to match those names.

Co-authored-by: Daniel Bauman <[email protected]>

Fixed a few broken links and converted a lot of them from the
html-link to intra-doc links.

This reworks `UninitSlice::as_uninit_slice_mut()` using equivalent
simpler logic.

I was a little confused about these calls using `Self::` instead of
`self.` here. Is there a reason to use the former instead of the latter?

Back in #362, an assertion was added to ensure that the alignment of
bytes::Shared is even so we can use the least significant bit as a flag.
bytes_mut::Shared uses the same technique but has no such assertion so
I've added one here.

Instead of re-declaring `vec`, we can just use a mut parameter.

These seem to have been commented by accident in #298, and are still
passing.

We're always subtracting here, and we already have a usize, so `sub`
seems like a more appropriate usage to me.

We don't need the original capacity if the shared data is unique, so
let's not calculate it until after that check.

The second argument to `set_vec_pos` always contains the value of
`self.data`. Let's just use `self.data` and remove the second parameter
altogether.

I can't see any reason that get_vec_pos needs a &mut self.

* set len a little more concisely
* inline set_end
* remove kind assertions
* remove a duplicate assertion
* remove redundant assertion and min
* rename set_start to advance_unchecked

CI is [failing][failure] due to unused_imports because Iterator is
already in the prelude. Removing it fixes things up.

[failure]: https://github.com/tokio-rs/bytes/actions/runs/8034858583/job/21946873895

Fixes #454.

Bytes doesn't have an unsplit method anymore. We can always retrieve
these from git history if necessary.

A fundamental invariant of `reserve` is that it can extend capacity
while the stored data remains the same, even if it's moved to a new
allocation. As a result, `len` can never change during a call to
`reserve`.

If `at == self.len()` then we already know `at <= self.len()`. If
`at == 0`, it can't be greater than `self.len()`.

Signed-off-by: tison <[email protected]>

…s (#691)

Closes #690
Without it, it seems to me that compiler is able to inline the vtable,
resulting in similar results for `clone_shared` and `clone_arg_vec`.

* use checked_sub

* return when additional == 0

* move safe operation out of unsafe block

* use spare_capacity_mut instead of chunk_mut

We don't need to check capacity because it's already been reserved
above.

* Add safety comments

* refactor to use guard clauses

This would be better written with let-else, but we won't get that until
`MSRV >= 1.65.x`.

* use if-let instead of unwrap

* reduce scope of unsafe blocks

Co-authored-by: Alice Ryhl <[email protected]>

---------

Co-authored-by: Alice Ryhl <[email protected]>