Xref: utzoo comp.unix.sysv386:8397 comp.lang.c:39564
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!caen!zaphod.mps.ohio-state.edu!wuarchive!emory!wa4mei!holos0!lbr
From: lbr@holos0.uucp (Len Reed)
Newsgroups: comp.unix.sysv386,comp.lang.c
Subject: Re: time(0L) - history of a misconception (was Re: SCO password generator)
Message-ID: <1991May24.151350.22705@holos0.uucp>
Date: 24 May 91 15:13:50 GMT
References: <1141@mwtech.UUCP> <381@tmcsys.UUCP> <1991May22.130713.25852@sco.COM>
Organization: Holos Software, Inc., Atlanta, GA
Lines: 26

In article <1991May22.130713.25852@sco.COM> david@sco.COM (David Fiander) writes:
>There exist architectures on which the NULL pointer is different from
>"all bits 0".  In fact, if you can get the compiler people to agree to
>it, the best value for the NULL pointer is something that is an invalid
>virtual memory address, because then, when somebody tries to dereference
>it, you get a core dump (note that 0 might be a valid address which would
>never be referred to by the user, for example: the address of the C
>startup code).

Under what architecture is a NULL pointer not "all bits 0"?  The problems,
as many have said, result when a pointer has fewer or more bits than
an integer (or a long).  NULL pointers *are* all zeros, though, since
casting zero to a pointer must yield a null pointer.  (Maybe there's
a loophole here in ANSI that says that (void *)0 is a null pointer but
the compiler could implement that casted zero as somthing other than
a pattern of zeros.  Not likely in the real world.)

You're certainly right that a NULL that produced a virtual memory fault
upon any use would be better than a virtual zero address.  But it's not
the "compiler people" who would have to agree to this.  Far too much
existing code would be broken by a move to this, I'm afraid.
-- 
Len Reed
Holos Software, Inc.
Voice: (404) 496-1358
UUCP: ...!gatech!holos0!lbr