Closed sdroege closed 10 months ago
I've pushed out a fresh version with a handy new read_as
method in the ByteRead
trait which takes a second endianness generic argument, overriding whatever the reader was using previously for that specific read.
Hopefully that'll work a bit better.
Thanks, that solves it and is a bit more consistent with the existing APIs than my suggestion.
@tuffy I saw you only added that for the byte read-side of things. Can you add the same to the write trait, and the two bit-based traits? Thanks again :)
This is now fixed in version 2.2.0, least for reading/writing whole values. Reading/writing values with a partial number of bytes in a different endianness could also be added, but its output is nonintuitive and I'm unaware of any actual file formats that work that way.
I agree. Thanks again :)
My situation here is that I have a
FromByteStream
implementation where the endianness of the integers that are going to be read is fixed and not something the caller should be able to decide. However when creating aByteReader
, exactly that is happening.Currently I work around this by using
u32::from_be_bytes(r.read::<[u8; 4]>()?)
but that is of course not as nice asr.read::<u32>()?
.Do you have any suggestions how to handle this? Would it maybe make sense to add something like an explicit
r.read_le::<u32>()
/r.read_be::<u32>()
/r.read_ne::<u32>()
etc for this situation?