sdroege / byte-slice-cast Goto Github PK

For example: https://docs.rs/byteorder/latest/byteorder/index.html#types

Can be done via Vec::from_raw_parts and would have the same rules as the slice casting. Ideally we can re-use the most of the infrastructure here.

Would be useful for servo-media so that we can avoid copies at the sink.

The following conversion fails with the AlignmentMismatch error:

let slice: Vec<u8> = Vec::new();
let converted_slice = slice.as_slice_of::<u16>().unwrap();

It is more a question than an issue: can such conversions be made? It will make writing generic code easier.

This API is the exact API that I was imagining when I went to look for a crate like this. More generic even, which is cool.

The version is only at 0.2, but it's been sitting there for half a year it looks like. Is there something holding it back from being 1.0 or could it be version bumped?

Would you be open to supporting primitive arrays? Since the layout appear to be well defined, it should be safe to do so.

Would you be willing to pull the patch that adds support for tuples? It looks like the code is good to go and it is only a matter of adding impl_trait!((T, T)) for each type and then testing it.

I wouldn't go deep with the size of tuples and only implement pairs which I think is the most common case.

I'm trying to compile a project that depends on byte-slice-cast to a wasm32-unknown-emscripten target. However, when building in debug mode, I get the following weird error:

Compiling byte-slice-cast v0.3.5
Referencing function in another module!
  call void <badref>(i8* %22), !dbg !149
; ModuleID = 'byte_slice_cast.v1okijvo-cgu.15'
void (i8*)* <badref>
; ModuleID = '
error: could not compile `byte-slice-cast`.

Building in release mode works just fine. Compiling any project that depends on byte-slice-cast (even a simple hello world project that does nothing but has a dependency on it) to that specific target results in this error. Any ideas on why this is happening?

Hi, I am scanning the byte-slice-cast in the latest version with my own static analyzer tool.

Unsafe conversion found at: src/lib.rs:237:43: 237:70.

fn to_byte_slice<T: AsRef<[$to]> + ?Sized>(slice: &T) -> &[u8] {
    let slice = slice.as_ref();
    let len = slice.len() * mem::size_of::<$to>();
    unsafe {
        slice::from_raw_parts(slice.as_ptr() as *const u8, len)
    }
}

Unsafe conversion found at: src/lib.rs:248:47: 248:76.

fn to_mut_byte_slice<T: AsMut<[$to]> + ?Sized>(slice: &mut T) -> &mut [u8] {
    let slice = slice.as_mut();
    let len = slice.len() * mem::size_of::<$to>();
    unsafe {
        slice::from_raw_parts_mut(slice.as_mut_ptr() as *mut u8, len)
    }
}

Unsafe conversion found at: src/lib.rs:303:43: 303:70.

fn to_byte_slice<T: AsRef<[[$to; N]]> + ?Sized>(slice: &T) -> &[u8] {
    let slice = slice.as_ref();
    let len = slice.len() * mem::size_of::<[$to; N]>();
    unsafe {
        slice::from_raw_parts(slice.as_ptr() as *const u8, len)
    }
}

Unsafe conversion found at: src/lib.rs:314:47: 314:76.

fn to_mut_byte_slice<T: AsMut<[[$to; N]]> + ?Sized>(slice: &mut T) -> &mut [u8] {
    let slice = slice.as_mut();
    let len = slice.len() * mem::size_of::<[$to; N]>();
    unsafe {
        slice::from_raw_parts_mut(slice.as_mut_ptr() as *mut u8, len)
    }
}

This unsound implementation would create a misalignment issues. The T and [u8] are different types.

This would potentially cause undefined behaviors in Rust. If we further manipulate the problematic converted types, it would potentially lead to different consequences. I am reporting this issue for your attention.