Re: [TUHS] origins of void* -- Apology!

Ralph is right. You don't have to go any further than the old x86 implementations to find machines where the function pointers are bigger than the data pointers. Further void* both by the standard and by practical matter MUST have the format of char*. Any other type of pointer has to be convertible to void*/char* (as both must address the smallest addressable unit). Most machines, don't need to actually do any pointer conversion but more than a few do, mostly those that have word addressing as native. If I recall properly, the CRAY, which didn't really have byte addressing at all, natively, just had the byte offset into word encoded in high order bits. The UNIVAC has a quite rich "partial word" format encoded in the pointers. The HEP as well used the low order bits to switch the operand size as well as the offset into the word. This all works because conversion via normal means converted the from or to the void*/char* and whatever the other data pointer type, as it knows the type of both sides of the conversion. The BSD kernels however were ripe with what I call "conversion by union." It would store one pointer type into a union of one pointer type and retrieve it from another. Now this is officially undefined behavior (as is most use of sockaddr_t in the early days). I remember spending a few days running around the kernel "fixing" this when doing the HEP port. -----Original Message----- From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Ralph Corderoy Sent: Wednesday, November 8, 2017 12:45 PM To: tuhs(a)minnie.tuhs.org Subject: Re: [TUHS] origins of void* -- Apology! Hi Bakul, In C, ignoring POSIX, a void pointer is big enough to hold any pointer to data. Pointers to data may be different sizes. And a void pointer can't hold a function pointer, but all function pointers are defined to be the same size. Thus `void (*)(void)' can be used as a generic function pointer type and cast to other ones when needed. That's awful. Might as well say `return' occurs so often, it should have been `@'. :-) -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy