Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!hal!ncoast!allbery
From: allbery@ncoast.UUCP (Brandon S. Allbery)
Newsgroups: comp.sources.bugs
Subject: Re: Patch #2 to Pcomm v1.1
Message-ID: <12625@ncoast.UUCP>
Date: 30 Sep 88 00:44:17 GMT
References: <13900004@osiris.cso.uiuc.edu> <416@quintus.UUCP> <7782@bcsaic.UUCP>
Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery)
Followup-To: comp.sources.bugs
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 31

As quoted from <7782@bcsaic.UUCP> by paula@bcsaic.UUCP (Paul Allen):
+---------------
| 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:
| >>This patch will fix the problem that some people are having with 
| >>seqmentation faults (although I'm not convinced the problem isn't
| >>in their compiler).
| >
| >It isn't.  It's the famous *NULL bug.
| >
| >>! 	if (*lock_path != NULL && lock_path != NULL) {
| 
| 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.
+---------------

C makes no guarantee about the order of expression evaluation IN GENERAL.
However, it DOES guarantee the evaluation order of && and ||, as they are
intended not to evaluate the expression on the right of the expression on
the left is sufficient to determine the value of the compound expression
(i.e. for "&&" the LHS is zero, for "||" the LHS is non-zero).  Check out
K&R, Appendix A, sections 7.11 (&&) and 7.12 (||).

++Brandon
-- 
Brandon S. Allbery, uunet!marque!ncoast!allbery			DELPHI: ALLBERY
	  For comp.sources.misc send mail to <backbone>!sources-misc
comp.sources.misc is moving off ncoast -- please do NOT send submissions direct
ncoast's days are numbered -- please send mail to ncoast!system if you can help