Fix integer overflow in BlobVec::push for ZST

[stepancheg]

reserve_exact is no-op for ZST because self.item_layout.size() > 0 is always false.

bevy/crates/bevy_ecs/src/storage/blob_vec.rs

Lines 112 to 120 in daa8bf2

	pub fn reserve_exact(&mut self, additional: usize) {
	let available_space = self.capacity - self.len;
	if available_space < additional && self.item_layout.size() > 0 {
	// SAFETY: `available_space < additional`, so `additional - available_space > 0`
	let increment = unsafe { NonZeroUsize::new_unchecked(additional - available_space) };
	// SAFETY: not called for ZSTs
	unsafe { self.grow_exact(increment) };
	}
	}

Then in push we just increase .len ignoring integer overflow.

bevy/crates/bevy_ecs/src/storage/blob_vec.rs

Lines 232 to 237 in daa8bf2

	pub unsafe fn push(&mut self, value: OwningPtr<'_>) {
	self.reserve_exact(1);
	let index = self.len;
	self.len += 1;
	self.initialize_unchecked(index, value);
	}

[james7132]

I'm not sure how this resolves the bug mentioned in the PR description.

The Rust standard library also has an unchecked addition in Vec::push. The corresponding grow method for RawVec also makes explicit checks to see if it's handling a ZST, which this PR is changing to be an unconditional assertion instead of a soft check.

The problem in the PR description is valid. We should not allow BlobVec's len to overflow, but I don't think the changes here are appropriate for addressing it.

[stepancheg]

I'm not sure how this resolves the bug mentioned in the PR description.

Attempt to call resolve_exact(usize::MAX) with vec of len 20 will panic now.

The Rust standard library also has an unchecked addition in Vec::push

Because reserve calls above in std::vec::Vec guarantees that after call to reserve Vec has enough spare capacity. BlobVec::reserve_exact does not guarantee that. Which this PR fixes.

The corresponding grow method for RawVec also makes explicit checks to see if it's handling a ZST, which this PR is changing to be an unconditional assertion instead of a soft check.

This "soft check" is converted to panic in handle_reserve in the same file. Which is exactly the same this commit is doing: panicking on ZST in grow.

The removal of the check in reserve_exact means we do not guard against this panic.

I'm sorry, I don't understand.

This may cause panics on BlobVecs holding ZSTs

Correct. We should panic when attempting to add more than usize::MAX elements to BlobVec. It is the same behavior as Vec.

something that is not part of reserve_exact's defined interface, and something we must support.

The interface of reserve_exact is: if reserve_exact is successful (i.e. does not panic), push will be successful.

We should not allow BlobVec's len to overflow, but I don't think the changes here are appropriate for addressing it.

Is it possible you misunderstood this PR?

Otherwise, what do you suggest?

[stepancheg]

Added a test.

[james7132]

Thanks for clarifying how you were approaching this. I think I see what you were going for here. This also removes yet another low level unsafe function from bevy_ecs, so it generally seems like a win to me. Only nit is that this is reliant on the current BlobVec initialization for ZSTs and that implicit reliance is not documented.

[stepancheg]

Added more comments.

[stepancheg]

Rephrased comments.