From: Ezekiel Newren <ezekielnewren@gmail.com>
Date: Wed, 21 Jan 2026 21:00:15 GMT
Subject: Re: [PATCH 01/10] ivec: introduce the C side of ivec
Message-ID: <CAH=ZcbCNeYATxqAeXcGd9kkHzJq2y5BpMrChSzb215EHAjHsbg@mail.gmail.com>
In-Reply-To: <20260119204010.GA3148606@coredump.intra.peff.net>

On Mon, Jan 19, 2026 at 1:40 PM Jeff King <peff@peff.net> wrote:
>
> On Mon, Jan 19, 2026 at 01:21:04PM -0700, Ezekiel Newren wrote:
>
> > Ok..., is there a way to pad a field to the largest size needed so
> > that this also works on the harvard architecture? If C isn't even self
> > consistent then how are these structs going to be passed between C and
> > Rust (which is THE point of ivec)?
>
> If you make a union of the pointers, it will require the largest size
> and the strictest alignment requirement. So:
>
>   struct foo {
>         union {
>                 void *v;
>                 uint8_t *u8;
>         } ptr;
>         size_t len;
>   };
>
> would be a single struct you could use to store a void pointer _or_ a u8
> pointer. The one thing you shouldn't do there, though, is assign via one
> union member and read from the other. So I don't know if that helps you
> or not (I confess I have not followed this rust discussion at all, and
> know nothing about rust/c ABI compatibility, and just got roped in on C
> esoterica).
>
> > Or do we just tell the arcane Harvard architecture "too bad" Git won't
> > run on it anymore?
>
> Minor nit: the Harvard architecture is one where function pointers are
> not the same as data pointers. An int/char distinction can happen even
> on more common (von Neumann) machines.
>
> But I think we can rephrase your question as: are there real-world
> machines we care about that will have different pointer sizes, or can we
> ignore this issue for practical purposes?
>
> I don't know the answer. I suspect it probably is OK for Git not to run
> on the machines mentioned in that C faq. But:
>
>   1. Sometimes there are subtle implications of undefined behavior that
>      may cause a compiler (even for a sensible machine) to do unexpected
>      things. I don't know offhand if that is the case here.
>
>   2. There are some modern platforms in which pointers are a bit more
>      opaque than just numeric addresses. For example, we've had a few
>      patches dealing with questionable pointer usage to make things work
>      on CHERI Arm systems. I'm not sure if any of that would matter
>      here, though (IIRC, it was mostly that pointers were unexpectedly
>      large and had matching alignment requirements, but all of them
>      equally so).
>
> -Peff

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.