Patch #2 to Pcomm v1.1

[Jeff Lo]

In article <7782 at bcsaic.UUCP> paula at bcsaic.UUCP (Paul Allen) writes:
>In article <416 at quintus.UUCP> ok at quintus.UUCP (Richard A. O'Keefe) writes:
>>In article <13900004 at osiris.cso.uiuc.edu> hood at osiris.cso.uiuc.edu 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.

In most cases the order of evaluation is undefined. The exceptions
are &&, ||, ?:< and ','. So here you would want to reverse the order
of the original expression to make it correct; i.e.:

 	if (lock_path != NULL && *lock_path != NULL) {

In this case, if lock_path is equal to NULL, the second part of the
expression would never be evaluated, and you would never indirect
through the NULL pointer. You don't need to use nested if's. See the
section of K&R that deals with precedence, and the Reference Manual
section of K&R that discusses each of the operators for which the
order of evaluation is guaranteed.
-- 
Jeff Lo
..!{ames,hplabs,uunet}!elan!jlo
Elan Computer Group, Inc.
(415) 322-2450