Path: utzoo!attcan!uunet!wyse!vsi1!ames!mailrus!cornell!uw-beaver!fluke!ssc-vax!bcsaic!paula From: paula@bcsaic.UUCP (Paul Allen) Newsgroups: comp.sources.bugs Subject: Re: Patch #2 to Pcomm v1.1 Summary: Oops! Message-ID: <7818@bcsaic.UUCP> Date: 22 Sep 88 04:06:51 GMT References: <13900004@osiris.cso.uiuc.edu> <416@quintus.UUCP> <7782@bcsaic.UUCP> Reply-To: paula@bcsaic.UUCP (Paul Allen) Organization: Boeing Computer Services AI Center, Seattle Lines: 39 In article <7782@bcsaic.UUCP> paula@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@boeing.com Boeing Advanced Technology Center | ...!uw-beaver!ssc-vax!bcsaic!paula