Path: utzoo!mnetor!uunet!husc6!hao!noao!arizona!naucse!jdc
From: jdc@naucse.UUCP (John Campbell)
Newsgroups: comp.lang.c
Subject: Re: Header problems
Message-ID: <604@naucse.UUCP>
Date: 9 Mar 88 15:15:06 GMT
References: <2550049@hpisod2.HP.COM> <7412@brl-smoke.ARPA> <3351@chinet.UUCP> <25398@cca.CCA.COM>
Organization: Northern Arizona University, Flagstaff, AZ
Lines: 25
Summary: He's right, but...

In article <25398@cca.CCA.COM>, g-rh@cca.CCA.COM (Richard Harter) writes:
> >
> 	This comes up regularly.  There is nothing wrong defining NULL as
> 0; it does not make for non-portability.  The fault lies in passing NULL
> as an uncasted pointer across a calling sequence.  Since lint will tell
> you about this, there is no good reason for this happening.

I've enjoyed and appreciated Richard's contributions to the net these
past weeks, but he should realize that not all 'C' code is written on
unix.  I am (gasp) developing under VMS.  I don't have lint; VMS compiler
options are suppose to be all I need :-(.

A while back a program called check(1) was posted.  I could not, easily,
get this to work on VMS.  I looked at a local copy of the pre-processor
for gnu-c and decided I didn't want to try to get that working on VMS.
I should probably abandon VMS :-) but I get paid to work on it  
(paid to create code that might be non-portable due to not having a lint).

PS anyone know of VMS lints for free?
PPS who's writing the next ANSI lint?
PPPS Thanks, again, to Chris Torek for NULL sanity.
-- 
	John Campbell               ...!arizona!naucse!jdc

	unix?  Sure send me a dozen, all different colors.