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