Path: utzoo!attcan!uunet!wyse!vsi1!ames!mailrus!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: <837@proxftl.UUCP>
Date: 30 Sep 88 06:40:58 GMT
References: <7782@bcsaic.UUCP> <25069@teknowledge-vaxc.ARPA> <12246@steinmetz.ge.com> <7972@umn-cs.CS.UMN.EDU>
Reply-To: bill@proxftl.UUCP (T. William Wells)
Organization: Proximity Technology, Ft. Lauderdale
Lines: 31
Summary:
Expires:
Sender:
Followup-To:
Distribution:
Keywords:

In article <7972@umn-cs.CS.UMN.EDU> randy@cctb.mn.org (Randy Orrison) writes:
: |                                Comparing NULL with data types other
: |than pointers may (a) produce slow code or (b) produce code which
: |doesn't work correctly. I would suggest that:
: |
: |     if (lock_path != NULL && *lock_path != '\0')
: |
: |is easier to read and will avoid having the char->int->pointer
: |conversion done at runtime.
:
: Points (a) and (b) are both wrong.  Explicitly typing out 'NULL' and
: '\0' should NOT affect the code generated (in either speed or
: accuracy), since leaving them out implies comparison to 0, which is a
: constant and so any type conversion can be done at compile time.
: (Note that buggy compilers may get this wrong, but then... they're
: buggy.)

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
*lock_path != (char *)0.  While it is valid to compare a
*constant* zero expression to a pointer, it is not valid to
compare any other integral expression with a pointer, not even a
null pointer.  Therefore, the comparison with NULL could generate
a syntax error.

---
Bill

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