>>> OTOH [nil pointer that's not all-0-bits] breaks so much code,
>> Only code that's already broken (and perhaps whose brokenness just
>> hasn't yet been noticed).
> I was thinking that 'fixing' every use of calloc(), and bzero() to
> ensure that '0' (null pointer) is explicitely assigned to every
> pointer is probably an overhead we can manage without?

This sounds like "I don't want to have to write correct code because
it's too much overhead".

Or, perhaps you'd rather think of it as "I deliberately write off
portability to machines where nil-pointer is not all-0-bits because
it's too much overhead".

Either point of view is self-consistent and could lead to something
like what you said.

And either one is okay, provided you realize that that's what you're
doing and you accept the ensuing consequences.

Me, I'm still going to do it right, and nil out my pointers by
assigning to them rather than by bzeroing them.

> Casting function pointers to void * is rather more dangerous,

Perhaps - but if you're going to restrict your portability to machines
where a nil pointer is all-0-bits, is it really all _that_ much more
crippling to add on the restriction that data pointers are no smaller
than function pointers (and that all pointers are "really" memory
addresses, and thus it makes sense to cast a function pointer to a data
pointer)?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B