| byteorder.rs |
Byte order-aware numeric primitives.
This module contains equivalents of the native multi-byte integer types with
no alignment requirement and supporting byte order conversions.
For each native multi-byte integer type - `u16`, `i16`, `u32`, etc - and
floating point type - `f32` and `f64` - an equivalent type is defined by
this module - [`U16`], [`I16`], [`U32`], [`F64`], etc. Unlike their native
counterparts, these types have alignment 1, and take a type parameter
specifying the byte order in which the bytes are stored in memory. Each type
implements the [`FromBytes`], [`AsBytes`], and [`Unaligned`] traits.
These two properties, taken together, make these types useful for defining
data structures whose memory layout matches a wire format such as that of a
network protocol or a file format. Such formats often have multi-byte values
at offsets that do not respect the alignment requirements of the equivalent
native types, and stored in a byte order not necessarily the same as that of
the target platform.
Type aliases are provided for common byte orders in the [`big_endian`],
[`little_endian`], [`network_endian`], and [`native_endian`] submodules.
# Example
One use of these types is for representing network packet formats, such as
UDP:
```rust,edition2021
# #[cfg(feature = "derive")] { // This example uses derives, and won't compile without them
use zerocopy::{AsBytes, ByteSlice, FromBytes, FromZeroes, Ref, Unaligned};
use zerocopy::byteorder::network_endian::U16;
#[derive(FromZeroes, FromBytes, AsBytes, Unaligned)]
#[repr(C)]
struct UdpHeader {
src_port: U16,
dst_port: U16,
length: U16,
checksum: U16,
}
struct UdpPacket<B: ByteSlice> {
header: Ref<B, UdpHeader>,
body: B,
}
impl<B: ByteSlice> UdpPacket<B> {
fn parse(bytes: B) -> Option<UdpPacket<B>> {
let (header, body) = Ref::new_from_prefix(bytes)?;
Some(UdpPacket { header, body })
}
fn src_port(&self) -> u16 {
self.header.src_port.get()
}
// more getters...
}
# }
``` |
38866 |
| lib.rs |
|
343743 |
| macro_util.rs |
Utilities used by macros and by `zerocopy-derive`.
These are defined here `zerocopy` rather than in code generated by macros or
by `zerocopy-derive` so that they can be compiled once rather than
recompiled for every invocation (e.g., if they were defined in generated
code, then deriving `AsBytes` and `FromBytes` on three different types would
result in the code in question being emitted and compiled six different
times). |
32051 |
| macros.rs |
|
18558 |
| post_monomorphization_compile_fail_tests.rs |
Code that should fail to compile during the post-monomorphization compiler
pass.
Due to [a limitation with the `trybuild` crate][trybuild-issue], we cannot
use our UI testing framework to test compilation failures that are
encountered after monomorphization has complated. This module has one item
for each such test we would prefer to have as a UI test, with the code in
question appearing as a rustdoc example which is marked with `compile_fail`.
This has the effect of causing doctests to fail if any of these examples
compile successfully.
This is very much a hack and not a complete replacement for UI tests - most
notably because this only provides a single "compile vs fail" bit of
information, but does not allow us to depend upon the specific error that
causes compilation to fail.
[trybuild-issue]: https://github.com/dtolnay/trybuild/issues/241 |
4444 |
| third_party |
|
|
| util.rs |
|
35416 |
| wrappers.rs |
|
19993 |