Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: news.software.b,comp.lang.c
Subject: Re: News for Xenix on PC AT ?
Message-ID: <5794@brl-smoke.ARPA>
Date: Sat, 25-Apr-87 19:37:55 EDT
Article-I.D.: brl-smok.5794
Posted: Sat Apr 25 19:37:55 1987
Date-Received: Sun, 26-Apr-87 21:56:07 EDT
References: <18346@ucbvax.BERKELEY.EDU> <145@sds.UUCP> <17005@sun.uucp> <146@sds.UUCP> <5787@brl-smoke.ARPA> <888@viper.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 25
Xref: mnetor news.software.b:546 comp.lang.c:1893

In article <888@viper.UUCP> john@viper.UUCP (John Stanley) writes:
>	myfunc( i1, NULL, i2 );
>
>If you use NULL as a pointer, it -must- always actualy be a pointer or
>your code will break any time you try to pass it as a constant to a 
>function.

No matter what NULL is defined as, the above usage is non-portable and
will break on some systems.  The problem is that the widths of pointers
of various types are in general different (and different from an (int)),
so that the wrong parameter alignment will occur unless one happens to
be lucky.  If you pass NULL as a function parameter, you should always
cast it to the correct pointer type, as in
	myfunc( i1, (struct foo *)NULL, i2 );

It is certainly true that there is a lot of code that makes this
mistake; I must have fixed several hundred occurrences of this
particular bug by now.  That does not make it any less erroneous.

For implementations of the draft proposed American National Standard
for C, if a function prototype happens to be in scope, the compiler is
required to automatically convert the parameters to have types that
match the prototype.  That would let you get away with such sloppy
coding practice without ever realizing what is happening, which is why
some of us are opposed to automatic parameter type coercion.