Copilot commented on code in PR #12149:
URL: https://github.com/apache/arrow-rs/pull/12149#discussion_r4529356333
##########
arrow-array/src/array/byte_array.rs:
##########
@@ -200,6 +203,44 @@ impl<T: ByteArrayType> GenericByteArray<T> {
}
}
+ /// Create a new [`GenericByteArray`] where `value` is repeated
`repeat_count` times.
+ ///
+ /// # Errors
+ ///
+ /// Returns an error if value's length multiplied by `repeat_count`
overflows `usize`
+ /// or exceeds `T::Offset::MAX`.
+ ///
+ /// # Example
+ /// ```
+ /// # use arrow_array::{Array, StringArray};
+ /// let array = StringArray::try_new_repeated("hello", 3).unwrap();
+ /// assert_eq!(array.len(), 3);
+ /// assert_eq!(array.value(0), "hello");
+ /// ```
+ pub fn try_new_repeated(
+ value: impl AsRef<T::Native>,
+ repeat_count: usize,
+ ) -> Result<Self, ArrowError> {
+ let s: &[u8] = value.as_ref().as_ref();
+ let value_offsets = OffsetBuffer::try_from_repeated_length(s.len(),
repeat_count)
+ .map_err(|err|
ArrowError::OffsetOverflowError(err.value().unwrap_or(usize::MAX)))?;
Review Comment:
`try_from_repeated_length` is not fully fallible for this input: after the
overflow checks it builds `(0..=n)` with an infallible `collect::<Vec<_>>()`.
For example, `LargeBinaryArray::try_new_repeated(b"x", i64::MAX)` passes the
`i64`/`usize` checks but the offset vector itself cannot be
represented/allocated and can panic instead of returning `Err`. Please make the
offset-buffer construction allocation-fallible (or validate the offset-buffer
allocation size) before exposing this as a fallible constructor.
--
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]
