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

[Joseph G. Toth Jr.]

In article <6001 at goanna.cs.rmit.oz.au>, ok at goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> Yes, void ** is valid, and it means pointer-to-generic pointer.
> Note that void ** itself may be represented some other way entirely;
> void ** is not itself a generic pointer.
> 
> In article <AJ3U.91May27213633 at jade.cs.virginia.edu>, aj3u at jade.cs.virginia.edu (Asim Jalis) writes:
> 
> [original post deleted]
>

[description of why there was deception, and why there were warnings, deleted]

> The compiler is RIGHT.  You promised it (oh, you deceiver) that
> you would give func() pointers to generic (void*) pointers
> (call the representation of generic pointers REPRESENTATION 0)
> But you lied (oh, you scoundrel, you).  You gave it
>     -- a pointer to (a pointer to int  -- REPRESENTATION 1)
>     -- a pointer to (a pointer to float -- REPRESENTATION 2)
>     -- a pointer to (a pointer to char -- REPRESENTATION 0)
> char* and void* use the same representation.
> But void*, int*, and float* need not even be the same _size_, let
> alone use the same physical representation.

Maybe, on different machines.o
My Apple //e running HyperC uses 16 bit pointers (always).

The IBM's we use at work with Microsoft C use the same size pointers
   as defined in the manual (always).

The HP9000/300 series I use at work uses 64 bit pointers (always).

On a single machine, the size of the pointer is based upon the
addressable range of memory, and is always the same _size_.
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.

But it just isn't so.

> 
> > The code itself works fine,

And well it should...


> 
> no, there is a bug in there, waiting, like a blood-sucking insect
> poised on a bush waiting for a deer to pass by, for an opportunity to bite.
> 

No there isn't. (see above)

> > Basically what I want is a type that would coerce to a pointer to a
> > pointer to a type, for any type.  Sort of one level beyond simple
> > "void *".
> 
> Why do you want to do _that_?  If you _could_ do it, you would be
> throwing away information that the receiver would need in order to
> be able to _use_ the thing?  What's the context?

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. The functions
use either the value (long, int, char, etc.) and use the value  (for
printf functions only), or the pointer (char *, int *, float *, etc.)
in the appropriate way based upon the information in the format string.
This is about the most 'bug' prone method of an implementation I've
ever seen, yet they are the primary method of I/O.

> 
> -- 
> 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.

This should also include;
  "force him to program in 'C', a pseudo-high level assembly language"

--
------------------------------------------------+---------------------
Maybe I shouldn't have done it, sarcasm is so   | Joseph G. Toth Jr.
seldom understood.  Don't FLAME on me, please.  | uunet!tellab5!toth