Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Header problems
Message-ID: <7428@brl-smoke.ARPA>
Date: 9 Mar 88 19:09:24 GMT
References: <2550049@hpisod2.HP.COM> <7412@brl-smoke.ARPA> <3351@chinet.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 22

In article <3351@chinet.UUCP> dag@chinet.UUCP (Daniel A. Glasser) writes:
>In article <7412@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>>	#define NULL 0
>Your use of NULL === 0 promotes unportable code, and is considered to be
>bad programming style in a world where portability across multiple machine
>architectures (ie, PDP-11, VAX-11, M680x0, I80x86 and Z800x) is required
>for commercial reasons.
>	#define	NULL	((void *)0)

My original advice was precisely correct.  Yours perpetuates the myth
that all pointers have the same representation.  Since this is not so
in general, there is no alternative for the portable C programmer but
to explicitly cast 0 or NULL to the proper type when it is used as a
function parameter.

For ANSI C, your suggestion is as good as mine (but no better); in
non-ANSI C, there is no (void *).  ANSI C has the additional advantage
that either form of NULL used as a function parameter will be
automatically converted to the right type, if a non-variadic function
prototype is in scope.

It seems that we have to go through this discussion every six months.