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

[Randy Orrison]

In article <837 at proxftl.UUCP> bill at proxftl.UUCP (T. William Wells) writes:
|In article <7972 at umn-cs.CS.UMN.EDU> randy at cctb.mn.org (Randy Orrison) writes:
---Bill Davidsen wrote:
|: |     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
		      ^             ^^^^  where'd this come from?
|*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.

Who's comparing a character to NULL?  I still stand by my statement
that leaving out the NULL or '\0' (from the quoted statement above) is
no different from putting them in.  Now, putting NULL in instead of
'\0' is something different entirely.

        -randy-- 
Randy Orrison, Chemical Computer Thinking Battery  --  randy at cctb.mn.org
randy at ux.acss.umn.edu	{bungia, uunet!hi-csc, rutgers, sun}!umn-cs!randy
Never put off till tomorrow what you can avoid all together.