Path: utzoo!attcan!uunet!wyse!vsi1!ames!mailrus!ukma!gatech!sbmsg1!itm!danny From: danny@itm.UUCP (Danny) Newsgroups: comp.sources.bugs Subject: Re: Patch #2 to Pcomm v1.1 Summary: "&&" guarantees left to right evaluation Message-ID: <1238@itm.UUCP> Date: 22 Sep 88 12:42:16 GMT References: <13900004@osiris.cso.uiuc.edu> <416@quintus.UUCP> <7782@bcsaic.UUCP> Reply-To: danny@itm.UUCP (Danny) Organization: In Touch Ministries, Atlanta, GA Lines: 31 In article <7782@bcsaic.UUCP> paula@bcsaic.UUCP (Paul Allen) writes: ~In article <416@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: ~> ~>It isn't. It's the famous *NULL bug. ~> ~>>! 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. Sorry, wrong. See page 190, section 7.11: "Logical AND operator" in K&R. "Unlike &, && guarantees left-to-right evaluation; moreover the second operand is not evaluated if the first operand is 0." The above line should read: if (lock_path != NULL && *lock_path != NULL) { -or- if (lock_path && *lock_path) { Left to right evaluation of logical connectives and short-circuiting is one of the nicest aspects of C! If your compiler doesn't do it, it's not a C compiler. Complain loudly to your vendor. Danny -- Daniel S. Cox (seismo!gatech!itm!danny)