From: Ezekiel Newren <ezekielnewren@gmail.com>
Date: Mon, 19 Jan 2026 20:21:04 GMT
Subject: Re: [PATCH 01/10] ivec: introduce the C side of ivec
Message-ID: <CAH=ZcbCXAB3vzRbyHkunQh09njyLk4WXvfLVxynXaswEkBv+DA@mail.gmail.com>
In-Reply-To: <20260119055947.GA3100271@coredump.intra.peff.net>

On Sun, Jan 18, 2026 at 10:59 PM Jeff King <peff@peff.net> wrote:
>
> On Sat, Jan 17, 2026 at 05:40:08PM +0000, Phillip Wood wrote:
>
> > On 17/01/2026 16:14, Ezekiel Newren wrote:
> > >
> > > If the size of different kinds of pointers ever differed from the size
> > > of void* then wouldn't that make all calls to malloc undefined?
> >
> > I believe there are (Havard architecture?) platforms where function pointers
> > are a different width to data pointers, and that's why you cannot store a
> > function pointer in void*. I agree it would be weird for char* to have a
> > different width to int*, I suspect the restrictions on casting from one type
> > to another are about alignment.
>
> The standard does allow for different pointer sizes for char and int.
> The key thing is that a void pointer has to be able to represent any. So
> you can cast a smaller pointer to void and vice versa (and the latter
> would presumably throw away some of the bits, which is OK as long as the
> void was made from one of those smaller pointers originally).
>
> More discussion at:
>
>   https://c-faq.com/null/machexamp.html
>
> I don't know how malloc worked on those platforms, though. The caller
> knows that malloc returns a void pointer, so it could cast to the
> smaller format in the usual way at the call-site. But I don't know how
> you would tell malloc() in a standard way what type of pointer you
> wanted to get out of it. I suspect they may have had specialized
> allocation functions. Or maybe it was enough to just throw away the low
> bits if you only cared about a word-addressable pointer.
>
> At any rate, yeah, I agree with your original concern that the two
> structs are not compatible. The layouts could be totally different. And
> not just due to pointer size, but IIRC pointers to different types could
> have different alignment requirements. So:
>
>   struct foo_void {
>         size_t len;
>         void *ptr;
>   };
>
>   struct foo_u8 {
>         size_t len;
>         uint8_t *ptr;
>   };
>
> might need different padding to properly align the pointers. In the case
> under discussion the pointers are always at the start, though, so I
> think it wouldn't matter.
>
> -Peff

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)?

Or do we just tell the arcane Harvard architecture "too bad" Git won't
run on it anymore?