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