From: Phillip Wood <phillip.wood123@gmail.com>
Date: Sat, 17 Jan 2026 17:40:08 GMT
Subject: Re: [PATCH 01/10] ivec: introduce the C side of ivec
Message-ID: <6ae80903-3cc5-4017-9eac-0b3100b93b04@gmail.com>
In-Reply-To: <CAH=ZcbAogCpqg0RkKg1WjuAcuKyArDs4aP+k=McCs_byDT2Weg@mail.gmail.com>

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.

> I
> don't see this as a problem since I'm not casting between structs with
> different members that are not pointers.

But isn't that is still undefined behavior as far as the C standard is 
concerned? It might make sense for it to work, but common sense has 
little to do with undefined behavior.

> I could use void* for
> everything, but then we'd need an accessor like *(T*)ivec_at(&vec, i),
> but this is much more painful and error prone than simply vec.ptr[i].

Yeah that's horrible

Thanks

Phillip