byteorder

byteorder is a small, dependency-free Rust crate that provides convenience methods for encoding and decoding numeric types in either big-endian or little-endian byte order. It centers on a ByteOrder trait with two implementations, BigEndian and LittleEndian, plus NetworkEndian and NativeEndian aliases for clarity, giving callers explicit, type-parameterized control over byte order at every read/write site.

For consumers of std::io, the crate extends the standard Read and Write traits via ReadBytesExt and WriteBytesExt, so numbers can be read from or written to any stream with a single generic method call (rdr.read_u16::<BigEndian>()). It supports no_std environments by disabling the std feature, and automatically provides i128/u128 support on compilers that support it, making it a common low-level building block for binary protocol and file-format parsers.

What You Get

• A ByteOrder trait implemented by BigEndian and LittleEndian types for converting between byte slices and every standard numeric type
• ReadBytesExt/WriteBytesExt extension traits that add generic read_u16::<E>()/write_u32::<E>()-style methods to any Read/Write implementor
• NetworkEndian and NativeEndian aliases for expressing intent (wire-protocol vs. platform-native ordering) without hardcoding a specific endianness
• Automatic i128/u128 support on compilers where 128-bit integers are available
• no_std compatibility via a default-on std feature that can be disabled for embedded or kernel-level use

Common Use Cases

• Parsing binary file formats (image headers, archive formats, serialized data) that specify a fixed byte order
• Implementing network protocol codecs where multi-byte fields are transmitted in network (big-endian) byte order
• Writing embedded or no_std firmware code that needs precise control over byte layout without pulling in the standard library
• Building low-level binary serialization/deserialization layers underneath higher-level format crates

Under The Hood

Architecture - The crate’s public surface lives almost entirely in src/lib.rs (roughly 3,900 lines), centered on a ByteOrder trait with read_uN/write_uN-style methods for every integer width, implemented once each for the zero-sized BigEndian and LittleEndian marker types. src/io.rs is a separate, std-gated module that defines ReadBytesExt/WriteBytesExt as blanket extension traits over std::io::Read/Write, so any stream type automatically gains the generic read_u16::<BigEndian>() style methods without needing a wrapper type. Internal helpers like extend_sign/extend_sign128 handle sign-extension for reading signed integers of non-native widths (e.g. read_i24). Tech Stack - the crate has zero mandatory runtime dependencies; quickcheck and rand are dev-only dependencies used for property-based testing of the read/write round-trip behavior across all supported widths and both endiannesses. #![no_std] is applied conditionally via cfg_attr when the std feature is disabled, and core:: primitives (slice, ptr::copy_nonoverlapping, mem::align_of) are used directly for the low-level byte manipulation. Code Quality - the crate enforces #![deny(missing_docs)], meaning every public item must be documented, and ships roughly 32 #[test]/mod tests blocks combining unit tests and quickcheck-based property tests that round-trip every integer width through both endian orderings. Doc-comments embed compiling, runnable examples (read_u16::<BigEndian>()) that double as documentation tests. API Design - the API pushes byte order into the type system as a generic parameter rather than a runtime argument, which eliminates an entire class of “wrong endianness at runtime” bugs at the cost of slightly more verbose call sites (::<BigEndian>() turbofish syntax); this trade-off, plus the small number of exported items (one trait, two marker types, two extension traits), keeps the crate’s learning curve low despite the exhaustive per-width method surface.