From: Jeff King Date: Wed, 21 Jan 2026 21:20:24 GMT Subject: Re: [PATCH 01/10] ivec: introduce the C side of ivec Message-ID: <20260121212024.GC723458@coredump.intra.peff.net> In-Reply-To: On Wed, Jan 21, 2026 at 02:00:15PM -0700, Ezekiel Newren wrote: > What about adding clar unit tests to make sure that different ivec > types have the same size and layout? e.g. sizeof(IVec_c_void) == > sizeof(IVec_u8); > sizeof(IVec_c_void) == sizeof(IVec_u16); > sizeof(IVec_c_void) == sizeof(IVec_u32); > sizeof(IVec_c_void) == sizeof(IVec_u64); > ... > > As well as other tests for ivec. I'm a little hesitant in general to have run-time tests for properties around undefined behavior, just because the compiler is allowed to do a lot of tricky things when we get into that territory. Plus it is not really _solving_ the problem, but perhaps just alerting us slightly sooner than the production code itself crashing and burning. You'd also need to check the pointer field sizes directly due to padding. I don't think it's sufficient, due to padding. If one pointer is 4 bytes and another is 8 (for example), but the element afterwards requires 8-byte alignment, then the compiler will have to insert 4 bytes of padding. And the resulting struct size will be the same. You'd have to more directly check that sizeof(uint_t*) == sizeof(void *), I think. So I dunno. I am not a compiler expert, nor a rust expert, nor really know anything about rust/C ABI boundaries. There might be no problem at all here, and I'm only commenting on what I know is possible (albeit unlikely) from the C side. -Peff