rluvaton opened a new pull request, #10118:
URL: https://github.com/apache/arrow-rs/pull/10118
# Which issue does this PR close?
- Closes #10117
# Rationale for this change
change for `Buffer::into_mutable` will lead to panic in case of owned sliced
buffer when offset is greater than 0
and will lead to confusing behavior (roundtrip will have different length)
when called with sliced buffer when offset is 0 but length is less than
underlying data length
the addition of the `Buffer::into_mutable_unsliced` is to allow getting the
`MutableBuffer` regardless of the sliced, and the user will be aware of that
the returned MutableBuffer can have different length and more data
the addition of `Buffer::is_sliced` so the user can know if the buffer is
sliced and act accordingly
# What changes are included in this PR?
1. updating `Buffer::into_mutable` to disallow converting to mutable in case
of sliced buffer regardless of offset
2. Added `Buffer::into_mutable_unsliced` to allow the user getting the
entire unsliced data in `MutableBuffer` and the user is aware of the
implications
3. added `Buffer:is_sliced`
# Are these changes tested?
yes
# Are there any user-facing changes?
yes, new functions and 1 breaking change - call to `Buffer::into_mutable`
with buffer that is sliced from 0 to not the end of the underlying data will
now return `Err`
```rust
fn main() {
let bytes = vec![0_u8; 8];
let buffer = Buffer::from(bytes.clone());
let sliced = buffer.slice_with_length(4, 4);
drop(buffer);
sliced.into_mutable(); // <-- This will now return error instead of panic
let buffer = Buffer::from(bytes.clone());
let sliced = buffer.slice_with_length(0, 4);
drop(buffer);
sliced.into_mutable(); // <-- This will now return error instead of
returning MutableBuffer with data outside slice
}
```
--
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]
