Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!ll-xn!adelie!cdx39!jc
From: jc@cdx39.UUCP (John Chambers)
Newsgroups: comp.lang.c
Subject: Re: Use of NULL in UNIX & C (Was: Microport Unix -- Large Model Problems)
Message-ID: <513@cdx39.UUCP>
Date: Fri, 5-Dec-86 11:34:29 EST
Article-I.D.: cdx39.513
Posted: Fri Dec  5 11:34:29 1986
Date-Received: Sun, 7-Dec-86 03:08:46 EST
References: <1376@batcomputer.TN.CORNELL.EDU> <8957@sun.uucp> <250@rabbit1.UUCP>
Lines: 32
Summary: I've had this problem, too.  I suggest: #define NULLP ((char *)0)

> Newsgroups: net.lang.c

[Gee, I wish people wouldn't redirect followups to non-existent newsgroups! :-]

This has been a constant hassle in porting code to 68000s, 
because many C compilers give me 16-bit ints and 32-bit
pointers.  One of the most common examples:
	l = time(NULL);
gets a Segmentation Fault, because the NULL is #defined as
just 0, and only 16 bits of zeroes are stacked.  The routine
fetches them plus 16 bits of garbage and tries to store the
clock value there.

In general, it might be a good idea to define a bunch of nulls:
	#define NULLI ((int)0)
	#define NULLL ((long)0)
	#define NULLP ((char*)0)
	#define NULLR ((real)0)
	...

Now if there were only a way to ensure proper alignment in
printf() formats.  I've heard a rumor that there's a version
of lint somewhere that has an option to check for this.  The
2.11 news release bombed spectacularly here due to some printfs 
like:
	printf("... %x ... %s ...",p1,p2);

When I changed it to %lX it worked just fine.
-- 
	John M Chambers			Phone: 617/364-2000x7304
Email: ...{adelie,harvax,inmet,mcsbos,mit-eddie,mot[bos],rclex}!cdx39!{jc,news,root,usenet,uucp}
Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193