samueleresca commented on code in PR #8594:
URL: https://github.com/apache/arrow-rs/pull/8594#discussion_r2442508862
##########
arrow-array/src/builder/generic_bytes_view_builder.rs:
##########
@@ -356,17 +371,41 @@ impl<T: ByteViewType + ?Sized> GenericByteViewBuilder<T> {
let to_reserve = v.len().max(self.block_size.next_size() as usize);
self.in_progress.reserve(to_reserve);
};
- let offset = self.in_progress.len() as u32;
+ let offset: u32 = self.in_progress.len().try_into().map_err(|_| {
+ ArrowError::InvalidArgumentError(format!(
+ "In-progress buffer length {} exceeds u32::MAX",
Review Comment:
> I am unsure if this error is even reachable.
I think this is right. I wasn't able to trigger this. For the panic to
verify, it would need to skip the `flush_in_progress()` operation that happens
when the buffer reaches the required capacity.
On top of that, the `push_completed` used by the `flush_in_progress` asserts
on the `block.len()` (see below). Therefore, `let offset: u32 =
self.in_progress.len()` wouldn't be reached:
https://github.com/apache/arrow-rs/blob/d49f017fe1c6712ba32e2222c6f031278b588ca5/arrow-array/src/builder/generic_bytes_view_builder.rs#L273-L276
I'm proceeding by reverting this the `map_err` in the offset initialization.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
