Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!ut-ngp!infotel!pollux!bobkat!m5d
From: m5d@bobkat.UUCP (Mike McNally )
Newsgroups: comp.lang.c
Subject: Re: conditional expression evaluation question
Message-ID: <425@bobkat.UUCP>
Date: Fri, 16-Jan-87 15:40:41 EST
Article-I.D.: bobkat.425
Posted: Fri Jan 16 15:40:41 1987
Date-Received: Sun, 18-Jan-87 18:52:40 EST
References: <207@rebel.UUCP> <7519@utzoo.UUCP>
Reply-To: m5d@bobkat.UUCP (Mr Mike McNally)
Organization: Digital Lynx, Inc; Dallas, TX
Lines: 33
Summary: | is not ||

My small contribution to this silly topic:

    x = (*cp++ | *cp++ | *cp++);                                (1)
    if (x) ... /* or !x or whatever */

In computing the value to be assigned to the variable `x', the compiler
cannot short-circuit the expression.  This should be clear; in the
simpler case

    x = (a | b | c);

if the variable `a' contains zero, the compiler must still OR the
contents of `b' and `c' to determine the result.  These are bitwise
logical operators.  Short-circuiting these makes no more sense than
short-circuiting a sequence of multiplies as soon as one of the
operands evaluates to `1'.

I of course agree that a potential problem exists with (1) above.  If
the evaluation of `*cp++' is not atomic, and the increment could be
delayed, the result may be equal to the first byte of the series.  In
any case, `cp' must be incremented by `3' and both bitwise-OR operations
must be performed.  Oh well, I guess an optimizing compiler that 
delays the increments might realize this and skip the OR's...this
is getting ridiculous.

--
****                                                         ****
**** At Digital Lynx, we're almost in Garland, but not quite ****
****                                                         ****

Mike McNally                                    Digital Lynx Inc.
Software (not hardware) Person                  Dallas  TX  75243
uucp: {texsun,killer,infotel}!pollux!bobkat!m5  (214) 238-7474