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

> 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