How to test code on 16-bit usize?

I have a library that I intend to be portable. I want to make sure I'm not inadvertently assuming usize is at least 32 bits somewhere.

Is there a way to force usize to be 16 bit for testing?

3 Likes

Probably the oddest thing I could think of, but you could try adding type usize = u16; at the top of each file. Temporarily or behind a flag only used for testing, of course.

That's an interesting suggestion although it breaks in a few trivial use cases (e.g. you can't index a slice with a u16).

1 Like

Rust can be compiled to code that runs on the 8 bit AVR micro-controllers.

I presume usize is 16 bits there. So that would be a good test platform.

You won't be using anything from std though.

The target JSON provided in the article gives you that information:

{
  "target-pointer-width": "16",
  "data-layout": "e-P1-p:16:8-i8:8-i16:8-i32:8-i64:8-f32:8-f64:8-n8-a:8"
}

The specification for data-layout can be found in the LLVM IR documentation. This target has 16-bit pointers, so yes it can hypothetically work for this use case. Another alternative is using the built-in avr-unknown-gnu-atmega328 or msp430-none-elf targets, which both have 16-bit pointers.

There are some caveats, though; no standard library port for any of these targets is the biggest hurdle. -Z build-std does not work on 16-bit architectures because hashbrown only supports 32-bit and 64-bit. I was able to get cargo-xbuild to build a MSP430 target, but it's #[no_std] and may not work with OP's library at all...

They don't specify, but I assume if there is a need to target 16-bit architectures, their library would in fact be #[no_std] and they would also have an environment capable of running such a build. That's a lot of assumptions. ¯\_(ツ)_/¯