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 · 2 comments
Open

Zero integer types #2273

kupiakos opened this issue Jan 29, 2025 · 2 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

@joshlf
Copy link
Member

joshlf commented Feb 20, 2025

I definitely would like to see zerocopy support something like this (see also: #31), especially if we can support infallible &[ZeroU8] -> &T conversions where T: FromZeros, as some users have memory they know to be zeroed (e.g. pages allocated via mmap etc).

I'll give some thought to how this would best be represented in our API, but I'm broadly in support.

@kupiakos
Copy link
Contributor Author

Ah, sorry I didn't see the first issue; that is similar.

Hmm, is &[ZeroU8] -> &T where T: FromZeros + Unaligned a practical operation? It yields a span of zeroed memory, but without the pointer provenance to soundly mutate that memory (e.g. if passed to FFI). &mut [ZeroU8] -> &mut T is unsound. Box<ZeroU8> -> Box<T> is sound iff T: FromZeros + Unaligned (extend to non-1 align as appropriate). #1183 is the best solution, so long as 3P types can unsafely indicate that consuming self removes all invariants in the source type (i.e. it is an exclusively-owned-to-owned conversion), so an MMIO library can convert MmioBox<[u8]> to MmioBox<T>.

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

2 participants