Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!cwjcc!gatech!uflorida!novavax!proxftl!bill
From: bill@proxftl.UUCP (T. William Wells)
Newsgroups: comp.sources.bugs
Subject: Re: NULL again (was Re: Patch #2 to Pcomm v1.1)
Message-ID: <843@proxftl.UUCP>
Date: 3 Oct 88 05:49:11 GMT
References: <7782@bcsaic.UUCP> <25069@teknowledge-vaxc.ARPA> <12246@steinmetz.ge.com> <7972@umn-cs.CS.UMN.EDU> <837@proxftl.UUCP> <7999@umn-cs.CS.UMN.EDU>
Reply-To: bill@proxftl.UUCP (T. William Wells)
Organization: Proximity Technology, Ft. Lauderdale
Lines: 21
Summary:
Expires:
Sender:
Followup-To:
Distribution:
Keywords:

In article <7999@umn-cs.CS.UMN.EDU> randy@umn-cs.UUCP (Randy Orrison) writes:
: In article <837@proxftl.UUCP> bill@proxftl.UUCP (T. William Wells) writes:
: |Sorry, but you should reread the postings you appended to your
: |message.  Since NULL may be validly defined as (char *)0 (or void
: |*)0), the comparison *lock_path != NULL could be equivalent to
:                     ^             ^^^^  where'd this come from?

Not only does Pcomm have this in it, but comparisons of integral
types with NULL are all over its code.  Try egrep '\*.*NULL' * to
see what I mean.  Not all the lines resulting are wrong, but
quite a few are.

The moral: don't use NULL unless you are assigning to or
comparing with a character pointer.  Better yet: don't use NULL
at all.

---
Bill

You can still reach me at proxftl!bill
But I'd rather you send to proxftl!twwells!bill