Path: utzoo!utgpu!attcan!lsuc!hcr!jim
From: jim@hcr.UUCP (Jim Sullivan)
Newsgroups: comp.lang.misc
Subject: Re: Query re optimising hcrs
Message-ID: <3678@hcr.UUCP>
Date: 28 Jul 88 15:35:49 GMT
References: <561@etive.ed.ac.uk> <24414@think.UUCP>
Reply-To: jim@hcr.UUCP (Jim Sullivan)
Organization: HCR Corporation, Toronto
Lines: 40

In article <24414@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes:
>
>This should not be confused with the common optimization where boolean
>expressions are short-circuited even when non-short-circuit operators
>are used.  This can be done when the expressions don't have
>side-effects (just like above).  However, since boolean expressions
>only have two possible values, true and false, it is quite common for
>hcr implementors to assume that each value will occur a
>significant fraction of the time.  Under this assumption, the
>transformation of
>
>     if <complex-expr> & <simple-expr>
>     then <result>
>
>into
>
>     if <simple-expr>
>     then if <complex-expr>
>	  then <result>
>
>is reasonable.
>

Actually, it isn't.  Only if the order that logical expressions is calculated
is undefined is this optimization reasonable.  Otherwise, you must follow the
defined order.  C is like this.  If I have a logical expression, the expression
is evaluated left to right, and the evaluation stops when the answer to the
expression is known.  For example,

	if( a && b ) 

is true only when a and b are true, so if a is false, then the expression is
false.  This protects me from many bad things, like:

	if( (p != NULL) && (*p == VALUE) )

where I check that the pointer is good and then check the value.  Reorganize
this and all hell will break loose.

Jim Sullivan