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

[William E. Davidsen Jr]

In article <7972 at umn-cs.CS.UMN.EDU> randy at cctb.mn.org (Randy Orrison) writes:
| In article <12246 at steinmetz.ge.com> davidsen at crdos1.UUCP (bill davidsen) wrote:
| |  Bear in mind that NULL is not always zero, but rather that zero cast
| |to a pointer type is always NULL.
| 
| No.  The computer's internal representation of a null pointer may not
| be the same as the internal representation of the integer 0.  However,
| 'NULL' can always be #defined as '0'; see below for the reasons for
| this.  Don't confuse the convenient symbol 'NULL' with the internal
| representation of a pointer that doesn't point to anything.

  Just not true in the real world. There are hundreds of programs
written by "all the world's a VAX" types who use NULL as a pointer
(uncast) in procedure calls. The only way around this is to define NULL
as "(void *)0", and this is done by a number of compilers in actual
practice. dpANS states clearly that NULL "expands into an
implementation- dependent null pointerconstant" (pg 96, 4.1.5).
| 
| |				   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.)

  Having shown that NULL is a pointer type in practice and in standard,
consider that the steps to compare the destination of the pointer are:
	a) fetch the character using the pointer
	b) convert char -> int
	c) convert int to pointer (checking for zero which may be
	   an exception on this machine.
	d) compare the result of (c) with the value of the *pointer*
	   NULL.

Note that use of '\0' avoids step c and does the comparison as an int,
which may be faster. If you define the end of string *char* value as
	#define EOS ((unsigned char) 0)
you may be able to avoid promotion to int, depending on how the
implementor interprets the "must behave as if it did this" rules.

  If you continue to disagree, please cite some standards which support
your contensions, then I'll post some machine code generated on eight
machines and we can bore everyone to death.
-- 
	bill davidsen		(wedu at ge-crd.arpa)
  {uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me