Skip to content

[BUG] DType::from rejects S16, U16 and F16 #386

Description

@phil-opp

src/core/util.rs:76-81:

impl From<u32> for DType {
    fn from(t: u32) -> Self {
        assert!(DType::F32 as u32 <= t && t <= DType::U64 as u32);
        unsafe { mem::transmute(t) }
    }
}

The upper bound is DType::U64, which is 9. But the enum continues past it (src/core/defines.rs:112-139):

    U64 = 9,
    S16 = 10,
    U16 = 11,
    F16 = 12,

So the assert fires for three of the crate's own supported types. Array::get_type() (array.rs:427-432) is the caller, which means:

let a = randu::<half::f16>(dim4!(3, 3));
let t = a.get_type();     // panics
println!("{:?}", a);      // panics — Debug impl calls get_type()

This is not a version-skew problem — it's wrong against a correct 3.8 library, and has been since f16 support was added. It's also the inverse mistake to the one in AfError::from: that assert is too loose, this one is too tight.

Fix: bound at DType::F16 as u32, or better, use an exhaustive match with a clear error for unrecognised values. Note ArrayFire 3.10 adds s8 = 13, so a match would future-proof this.


Found by Claude Opus 5. Verified manually.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions