These types deliberately do not have any built-in implementations in binrw because their size varies depending on the target architecture, so using them directly is not portable. One of the goals of binrw is to avoid footguns like this where it is possible to accidentally use the library in a non-portable way.
If your goal is to read/write data into a field that is usize or isize, use e.g. #[br(try_map = u64::try_into)] to convert from the correct underlying fixed-size type.
If you are reading from a local socket or shared memory where the incoming data is itself target-machine-dependent, use parse_with and write_with and a helper function, or a newtype wrapper. A patch to add helper functions for reading/writing native usize/isize instead seems like it would be a fine addition to the library, since this is a use case that has come up in the past.
Hopefully this makes sense. Let me know if you have any questions or other feedback. Thank you again!
Hi there, and thanks for your contribution!
These types deliberately do not have any built-in implementations in binrw because their size varies depending on the target architecture, so using them directly is not portable. One of the goals of binrw is to avoid footguns like this where it is possible to accidentally use the library in a non-portable way.
If your goal is to read/write data into a field that is
usize
orisize
, use e.g.#[br(try_map = u64::try_into)]
to convert from the correct underlying fixed-size type.If you are reading from a local socket or shared memory where the incoming data is itself target-machine-dependent, use
parse_with
andwrite_with
and a helper function, or a newtype wrapper. A patch to add helper functions for reading/writing native usize/isize instead seems like it would be a fine addition to the library, since this is a use case that has come up in the past.Hopefully this makes sense. Let me know if you have any questions or other feedback. Thank you again!