if(p)

[Peter da Silva]

> > If nothing else you can always add a shim at 0000:0000 (or whatever weird
> > method you use for indicating segments)...
> 
> Shame on you Peter, for not reading the entire net.lang.c archives before
> asking this question :-).

You're right. I'll run right out & read them this very minute.

>                            Some while ago this very issue was raised:  some
> poor people were faced with implementing C on an architecture which did
> interesting things with the high-order bits of pointers, such that any
> attempt to treat an all-0 value as a pointer caused a trap.

Well, what was it doing with these high bits? Anything meaningful in terms
of where it's pointing? If not, you could always mask them out when doing
compares with a pointer.

>                                                              Not just any
> attempt to follow the pointer, mind you, but any attempt to do *anything*
> with it.  Trapping *NULL is one thing; trapping foo=NULL is unacceptable.
> So they could not use all-0 as NULL.

Um, treating an all-0 value as a pointer? But what operation do you do on
pointers apart from dereferencing that could be construed as doing something
with a *pointer* as opposed to doing something with a *variable*? Sounds like
some net.bizarre sort of tagged architecture, in which case you can throw
portability out the window anyway. I mean, what would this do to implicit type
conversion, just for starters? OK, let's rephrase that. What sort of
architecture could you actually implement 'C' on, and reasonably easily port
programs to and from, that wouldn't let you use 0 as a pointer?
-- 
Name: Peter da Silva
Graphic: `-_-'
UUCP: ...!shell!{graffiti,baylor}!peter
IAEF: ...!kitty!baylor!peter