> It would be safest never to try to encode a pointer into an integer.

This I agree with entirely.

> However, ptrdiff_t is defined to be an integer the size of a pointer,

I don't think this is quite true.  ptrdiff_t is defined to be an
integer of suitable size for storing the difference between two data
pointers, I believe.  This may be different from the size of a pointer,
or even the size of a data pointer.

For example, a machine might have 40-bit pointers, of which 32 bits are
memory address (4G address space) and 8 bits are some privilege foo.
Since the privilege bits are not really part of the address - two
pointers that differ only in the privilege bits would still refer to
the same spot in memory - ptrdiff_t could reasonably be only 32 bits,
and indeed arguably *should* be only 32 bits, even though pointers are
1.2 times that big.

> and standards-compliant systems should define this if <stddef.h> is
> included (or any standard header such as stdio.h, string.h, etc.).

Is including <stdio.h> really allowed to reserve the namespace
allocated for <stddef.h>?  I'd expect that if the program has not
explicitly included <stddef.h> then stddef.h-defined things like
ptrdiff_t would still be in user namespace.

Of course, my expectations have been wrong before. :-)  It may also
depend on whether the header is an ANSI-C-specified header or a
POSIX-specified header; I do recall hearing that POSIX has thrown a lot
more things into the mix than ANSI C did.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B