Re: [PATCH 01/10] ivec: introduce the C side of ivec

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Jan 17, 2026, 17:40 UTC
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