Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!elan!jlo
From: jlo@elan.UUCP (Jeff Lo)
Newsgroups: comp.sources.bugs
Subject: Re: Patch #2 to Pcomm v1.1
Message-ID: <351@elan.UUCP>
Date: 21 Sep 88 21:12:45 GMT
References: <13900004@osiris.cso.uiuc.edu> <416@quintus.UUCP> <7782@bcsaic.UUCP>
Reply-To: jlo@elan.UUCP (Jeff Lo)
Organization: Elan Computer Group, Inc., Palo Alto, CA
Lines: 29

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