pointer size

[Doug Gwyn]

In article <6218 at tellab5.tellabs.com> toth at tellabs.com (Joseph G. Toth Jr.) writes:
>On a single machine, the size of the pointer is based upon the
>addressable range of memory, and is always the same _size_.

Wrong.  The most common architectural cause of use of different sizes for
pointers to different types is a word-oriented machine where it takes
additional bits to select a byte within a word, so "char *" is then
implemented as a larger size than other object pointer types.  ("void *"
is represented the same as "char *".)  Another such situation occurs
when it takes more bits to fully represent function (I-space) addresses
that it does for data object (D-space) addresses.

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

There is no problem, if you use malloc()/free() correctly, for example
if you make sure it is properly declared before you invoke it, so it is
not treated as returning int.

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

This is entirely wrong.  A stack need not be used, but if it is, the
sizes of the arguments can vary from one argument to the next.  The
definition of the function uses the format specifiers to decide how to
pick up each argument, and a portable implementation will use <varargs.h>
or <stdarg.h> to do that.  The va_arg() macro takes a type argument,
specifically so it can pick up the correct amount of data in the correct
format from the set of arguments.

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

Maybe if you didn't treat C as an assembly language you might better
appreciate how to use it properly.