Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Zero integer types #2273

Open
kupiakos opened this issue Jan 29, 2025 · 0 comments
Open

Zero integer types #2273

kupiakos opened this issue Jan 29, 2025 · 0 comments
Labels
customer-request Documents customer requests.

Comments

@kupiakos
Copy link
Contributor

kupiakos commented Jan 29, 2025

We've implemented some protocols that are designed to require all-zeroes in segments of the message. We ended up making this statically required by defining wrapper types around an enum. Example for u32:

#[derive(Clone, Copy, Default, IntoBytes, Immutable, FromZeros)]
#[repr(u32)]
enum AlignedZeroU32 {
    #[default]
    Zero = 0,
}

#[repr(C, packed)]
#[derive(Clone, Copy, Default, IntoBytes, FromZeros, Immutable)]
pub struct ZeroU32(AlignedZeroU32);
impl PartialEq for ZeroU32 {
    fn eq(&self, other: &ZeroU32) -> bool { true }
}

impl fmt::Debug for ZeroU32 {
    fn fmt(&self, fmt: &mut fmt::Formatter<'_>) -> fmt::Result {
        // No need to debug the inner field.
        fmt.debug_struct("ZeroU32").finish()
    }
}

// PartialEq against u32 with `== 0`, U32<T: zerocopy::byte_order::ByteOrder> with `== U32::ZERO`

There were enough hurdles to jump through to implement this correctly that it'd be convenient to have these as types within zerocopy. This doesn't use zerocopy::Unalign<AlignedZeroU32> because PartialEq and Debug require manual implementations

@kupiakos kupiakos added the customer-request Documents customer requests. label Jan 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
customer-request Documents customer requests.
Projects
None yet
Development

No branches or pull requests

1 participant