Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ames!pacbell!att!cbnewsc!gregg
From: gregg@cbnewsc.ATT.COM (gregg.g.wonderly)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Fonts and freeing memory
Message-ID: <12915@cbnewsc.ATT.COM>
Date: 17 Jan 90 22:50:48 GMT
References: <9001161446.AA29551@en.ecn.purdue.edu>
Organization: AT&T Bell Laboratories
Lines: 38

From article <9001161446.AA29551@en.ecn.purdue.edu>, by bevis@EE.ECN.PURDUE.EDU (Jeff Bevis):
> Well, I wouldn't do that either, because you can't be sure what the compiler
> is going to do with your code.  You've got two expressions hooked together
> with a logical 'and' -- now which one will the final code try first?  The one
> on the right?  Uh-oh.  This is better:

C was designed by people who had more insight into reality than this.  Logical
expressions are guaranteed to evaluate from left to right so the original
code is indeed correct.  Your's is too, but changing it is not necessary to
get the desired behavior.

	i.e.


	if ((b = call_func_b ()) == NULL || (a = call_func_a(b)) == NULL) {
		
		/*  Do something, both didn't work. */

	}

	will call "call_func_a" if the first condition (call_func_b
	returning NULL) is false, but will not call "call_func_a" if
	"call_func_b" returns NULL.  This means that one can guarantee
	that the parameter to "call_func_a" will be the value returned
	from "call_func_b", and it will not be "NULL".

One of the nicest things about C is that the behavior of the compiler is
almost always defined for expression evaluation.  Excepting the classic
mistake of

	*p++ = *p & 0x7f;

which, is not guarateed to evaluate the *p on the right before the *p++
on the left of the assignment operator.

-- 
-----
gregg.g.wonderly@att.com   (AT&T bell laboratories)