[TUHS] origins of void* -- Apology!

Don Hopkins don at DonHopkins.com
Thu Nov 9 06:39:11 AEST 2017


> On 8 Nov 2017, at 20:56, Ron Natalie <ron at ronnatalie.com> wrote:
> 
> 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.

The PDP-10 had arbitrarily sized byte pointers! Did anybody ever implement a C compiler on that hardware?

https://stackoverflow.com/questions/3153141/defining-a-byte-in-c <https://stackoverflow.com/questions/3153141/defining-a-byte-in-c>

https://en.wikipedia.org/wiki/36-bit <https://en.wikipedia.org/wiki/36-bit>

As DIGEX teased the VAX weenies at DECUS:

“If you’re not playing with 36 bits, you’re not playing with a full DEC!"

-Don

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/47a7686e/attachment.html>


More information about the TUHS mailing list