rluvaton opened a new issue, #10117:
URL: https://github.com/apache/arrow-rs/issues/10117
### Describe the bug
calling `Buffer::into_mutable` on sliced owned buffer that is sliced from
the middle (e.g. start at 4 end at 8) will panic instead of returning an error
but calling `Buffer::into_mutable` on sliced owned buffer that is sliced
from the start (e.g. start at 0 end at 4) will not panic and return
MutableBuffer containing the entire unsliced buffer
### To Reproduce
```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);
// This will panic
sliced.into_mutable();
// but
let buffer = Buffer::from(bytes.clone());
let sliced = buffer.slice_with_length(0, 4);
drop(buffer);
// This will not panic
sliced.into_mutable();
}
```
### Expected behavior
1. it should not panic and return error regardless of slicing
2. it should not allow calling `into_mutable` on sliced `Buffer` as this
will lead to unexpected behavior
```rust
fn increment_i32(mut mutable: MutableBuffer) -> ScalarBuffer<i32> {
mutable
.typed_data_mut::<i32>()
.iter_mut()
.for_each(|num| *num += 1);
ScalarBuffer::<i32>::from(mutable)
}
fn main() {
let bytes = vec![0_u8; 8];
let buffer = Buffer::from(bytes);
let sliced = buffer.slice_with_length(0, 4);
drop(buffer);
let scalar = ScalarBuffer::<i32>::from(sliced);
let original_length = scalar.len();
let mutable: MutableBuffer = scalar.into_inner().into_mutable().expect("if
we allow the current behavior of supporting sliced buffer")
let output = increment_i32(mutable);
// this will fail as output.len() will equal 2 and not 1
assert_eq!(output.len(), original_length)
}
```
### Additional context
I alsio want a function that allow sliced regardless but it will be marked
unsafe since it will return data that is outside the slice, I will create a 2
prs for this
--
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]
