NULL again (was Re: Patch #2 to Pcomm v1.1)

T. William Wells bill at proxftl.UUCP
Fri Sep 30 16:40:58 AEST 1988


In article <7972 at umn-cs.CS.UMN.EDU> randy at 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



More information about the Comp.sources.bugs mailing list