[comp.lang.c] bitwise pointer formats

throopw@dg_rtp.UUCP (04/28/87)

> chris@mimsy.UUCP (Chris Torek)
>> lopez@uiucdcsp.cs.uiuc.edu
>> But I think that declaring:
>>#define NULL (char *)0
>>is expensive but will always do the trick for all models (small,large,huge)
> This is wrong:  It will not always work.  In fact, it will not work
> on at least two existing machines, both of which have C compilers.
> (DG MV series and PR1ME series have 48 bit char pointers, but 32
> bit word (integer, structure, &c) pointers.  Passing one (char *)0
> and one int to a function that expects one (int *)0 followed by one
> int will give you a much-deserved surprise.)

Well... first I want to reinforce Chris's main point, that is is NOT
safe to pass a pointer of a given type as an actual argument to a formal
argument that has some other pointer type.  This is true even of nil
pointer values.  Each and every time a nil pointer value is used as an
actual argument, it must be cast to the correct type, the type of the
formal argument.  This is dangerous, and there are machines out there
where this will bite you.  Data General machines are one of these
(though there are compiler options that will allow such incorrect code
to run on DG gear).

On the other hand, DG machines don't have 48-bit character pointers.  DG
machines have instructions to manipulate 32-bit long 16-bit granular
pointers, 32-bit long 8-bit granular pointers, and (to a lesser extent)
64-bit long 1-bit granular pointers.  Three (count 'em, three) different
pointer formats.  If a pointer of one format is passed to a pointer of a
different format, BLOOIE!!!  Your process gets a SIGSEGV.

It turns out that the nil pointer in all of these formats is
full-of-zeroes, as far as C is concerned in the default case.  But there
are instructions (and special compiler options that exploit these) that
make nil pointers have different values, in particular, all ones.

The upshot is, that on DG gear it is a horrible gaffe to pass a pointer
of one type to a routine that expects a pointer to another type.  The
resulting SIGSEGV soon puts the offending programmer on the correct
path.  It so happens that an exception is that all pointers share the
bitwise value for nil (or NULL), but you'd better not try to indirect
such a pointer, or BLOOIE... yep, you guessed it... SIGSEGV.

So don't mess around.  Pointers aren't typeless bags of bits, folks.
Pointers have types, and should be used in a type-correct manner.

--
"....ooooooooohhhhhhhhhhhhhhh   yeeeeeaaaaaaaaaaaaaaahhhhhhhh ..."
                        --- From soundrack of "The Secret of My Success"
-- 
Wayne Throop      <the-known-world>!mcnc!rti-sel!dg_rtp!throopw