pointer size (Was: Re: "void **" : Is it valid and what does it mean?)

[Richard A. O'Keefe]

In article <6218 at tellab5.tellabs.com>, toth at tellabs.com (Joseph G. Toth Jr.) writes:
> In article <6001 at goanna.cs.rmit.oz.au>, ok at goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> > But void*, int*, and float* need not even be the same _size_, let
> > alone use the same physical representation.

> Maybe, on different machines.
> [Appel //e, IBM PCs w/ Microsoft C, HP9000/300 use fixed-size pointers]

Well, bully for you.  But what I wrote is correct, nevertheless.

> On a single machine, the size of the pointer is based upon the
> addressable range of memory, and is always the same _size_.

I'm sorry, but I really do think you ought to think before you post.
The statement above is simply NOT TRUE.  The subject has been beaten
to death on comp.lang.c, and is explained in the FAQ.  Everyone should
read the FAQ list at least once a year.

The size of a pointer is NOT necessarily based on the addressable
range of memory.  For example, I used to use (and still like) a machine
where the addressable range of memory was 2^20 *words*, but a pointer
was 48 bits.  If I remember correctly, and it has been a long time,
a pointer was <size of thing pointed to {4,6,8,48, or 96 bits},
offset from base of array, address of array _descriptor_>.  There was
no such thing in that machine as a bare address.  After that, I used
a machine where int* values were 32 bits and char* values were 48 bits.
(Actually, I had to program that one in Fortran and Assembler, not C.)

> If it weren't, malloc and all of the other memory allocation functions
> would be meaningless, and a source of the 'blood-sucking insect (bug)'
> stated below.

This is also an incorrect statement.  But I'll leave the correction
for the computer architecture and/or programming language implementation
courses and books you have yet to take advantage of.
> Just look at printf ans scanf (and all their associated functions).
> The list of remaining values is effectively an array on the stack
> where the elements may or may not even be pointers.

Like, Wow.  This character doesn't understand argument passing any
better than addresses.  What makes you think there is a stack in memory
which can be addressed like an array?  It Ain't Necessarily So, and on
quite a lot of machines It Simply Isn't True.  (On a Prime, for example,
the procedure call mechanism ensures that what you get _is_ an array of
pointers.  No hardware pass by value on that machine!  On a VAX, the
arguments are an array, but they need not be on the stack.  On a SPARC,
the arguments are not in memory.)  I have to admit that I wrote a
version of printf() for a machine where the vendor's one had some bugs,
and my company really loved me when they ported it to another machine
and it broke, because the arguments on that machine were NOT "effectively
an array on the stack".

In short, before you criticise someone else's answers, make sure you
understand the problem.  Computer architectures _in use today_ are a
lot stranger than many people realise.
-- 
Should you ever intend to dull the wits of a young man and to
incapacitate his brains for any kind of thought whatever, then
you cannot do better than give him Hegel to read.  -- Schopenhauer.