🚀 go-pugleaf

> fgd3@jc3b21.UUCP (Fabbian G. Dufoe)
> ((b=1),b) doesn't do
> anything in this case which (b=1) doesn't do.

I'd like to reinforce what Fabbian said about (b=1) vs ((b=1),b).

I find that the Three Holy Documents of C (K&R, H&S, the draft ANSI
standard) are a little muddy on this point, though I agree with Fabbian.
In particular, just what value results from an assignment operator?  K&R
(191) says

    The value is the value stored in the left operand after the
    assignment has taken place.

H&S (184) say

    The type of the result is equal to the (unconverted) type of the
    left operand.  The result is the value stored into the left operand.

The draft ANSI standard (3.3.16) says

    An assignment expression has the type of the left operand and the
    value of the left operand after the assignment, but is not an
    lvalue.

Now, all of these statements can be read in two different ways.  It
could mean "the value of the expression is the value that was stored by
this assignment", or it could mean "the value that the left operand
actually has at some point *after* the assignment".  However, note well
the change in wording of the ANSI draft standard from K&R and H&S.  It
is *far* less plausibly interpreted in the former way, and *far* more
plausibly interpreted in the latter way.  Therefore, I agree with
Fabbian: the expressions ((b=1),b) and (b=1) mean very, very nearly the
same thing (in terms of "what value results").

And, in particular,

        a = (b=1) + (b=2);

is *just* *as* *dangerous* as

        a = ((b=1),b) + ((b=2),b);

(and, to pick a nit, might be a little *more* dangerous, since the
 first expression doesn't even contain sequence points.)

Just remember.  Don't *ever* have two different side-effects on a single
object in a single expression.  It's just asking for trouble.

--
Never has the such of this which been put to me here this way by anybody.
                                --- Carl Sandburg
-- 
Wayne Throop      <the-known-world>!mcnc!rti-sel!dg_rtp!throopw