Xref: utzoo comp.unix.sysv386:8359 comp.lang.c:39537
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!randvax!segue!jim
From: jim@segue.segue.com (Jim Balter)
Newsgroups: comp.unix.sysv386,comp.lang.c
Subject: Re: time(0L) - history of a misconception (was Re: SCO password generator)
Message-ID: <7649@segue.segue.com>
Date: 23 May 91 22:38:38 GMT
References: <588@sherpa.UUCP> <1141@mwtech.UUCP> <381@tmcsys.UUCP> <1991May22.130713.25852@sco.COM>
Reply-To: jim@segue.segue.com (Jim Balter)
Organization: Segue Software, Inc. - Santa Monica, CA. +1-213-453-2161
Lines: 23

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".

This isn't relevant if using ANSI prototypes, since any form of zero is
implicitly converted to the appropriate null pointer, no matter how it is
represented.  If you aren't using ANSI prototypes, then you should manually
cast everything into the proper type, and run lint religiously.  Hopefully,
some day, we will only concerned with the first case.

>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).

This doesn't require a non-zero representation of NULL, since page 0 of
the virtual address space can usually be made inaccessible.  Most UNIX systems
don't do it because there are too many bad UNIX programs written by too many
bad UNIX programmers, and any desire to do the "right" thing is overridden
by the market demand to allow programs that dereference NULL to continue to
"work".