Patch #2 to Pcomm v1.1

[Paul Allen]

In article <7782 at bcsaic.UUCP> paula at bcsaic.UUCP (Paul Allen) writes:
>>
>>>! 	if (*lock_path != NULL && lock_path != NULL) {
>>
>>This only tests whether lock_path is legal *after* trying to use it!
>
>I've now seen a couple postings about this bug, but nobody has got it
>right yet!  What has been missed is that C makes no guarantee about the
>order of expression evaluation.  The only safe way to perform this test
>is using two nested if statements.
>
>I'll be quiet now.
>Paul

I should have kept my mouth shut!  I just found messages in my inbox from
Rich $alz and Bob Wilber (thanks, guys!) pointing out my error.  What I
remembered reading is on page 49 of K&R:

	"C, like most languages, does not specify in what order the
	operands of an operator are evaluated."

However, in Appendix A we find:

	"Unlike &, && guarantees left-to-right evaluation; moreover the
	second operand is not evaluated if the first operand is 0."

Geez, just think of all the keystrokes I've wasted on coding nested if's
to test for NULL pointers!  :-)

And now, as evening settles in and I prepare to wend my way home, 
countless messages of gentle correction are journeying through the
night, passing swiftly from machine to machine, unswervingly intent
upon filling my mailbox with joy!  Ain't the net wonderful?

Paul
-- 
------------------------------------------------------------------------
Paul L. Allen                       | paula at boeing.com
Boeing Advanced Technology Center   | ...!uw-beaver!ssc-vax!bcsaic!paula