Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!orion.oac.uci.edu!unogate!unocal!genisco!arcturus!berry
From: berry@arcturus.uucp (Berry;Craig D.)
Newsgroups: comp.lang.c
Subject: Re: Circumspect programming (was: Evaluation of if's)
Message-ID: <1991Jun24.202840.26091@arcturus.uucp>
Date: 24 Jun 91 20:28:40 GMT
References: <1991Jun20.012131.26756@athena.mit.edu>
Organization: Rockwell International
Lines: 48

scs@adam.mit.edu (Steve Summit) writes:

>Now, it may be that some of the people who are keeping this
>thread alive aren't really worried about the (undefined)
>expression

>	(i = 1) == (i = 2)

>at all, but are rather simply wondering whether the value of the
>expression

>	i = 1

>is "one" or "the value of i."  (There have even been suggestions
>made that the answer is somehow different for ANSI C than
>"Classic" C, and that the ANSI Standard answer therefore isn't
>relevant for pre-ANSI compilers.)

>This starts looking like a hard question to answer, because you
>can't find words in the Standard (or in any number of C reference
>books) which explicitly answer it.  The answer isn't written down
>explicitly because it's so simple: *it doesn't matter*.  It is
>defined that the value of an assignment statement is the value of
>the right-hand side, cast to the type of the left-hand side.  In
>a correct program (one which doesn't have multiple assignments,
>within the same expression, to the same object, in particular to
>the one on the left-hand side) there is absolutely no detectable
>difference between "the value of the right-hand side, cast to the
>type of the left-hand side" and "the value (after the assignment)
>of the left-hand side," because "the value of the right-hand
>side, cast to the type of the left-hand side" is precisely what
>gets assigned to the left-hand side.

I am straining my memory somewhat here, but I recall reading an 
article somewhere (Dr. Dobb's?  Computer Language?) on the semantics
of C under ANSI standard floating point operations.  One point raised
was that ANSI C specifically removes the requirement for "knothole"
casts to floats; e.g., if you have an 80-bit value in a floating point
register, and you cast it to double (say, (double) (5.0 * 3.0)), the
extra 16 bits (assuming 64-bit doubles) are *not necessarily* scraped
off by the cast.  This could effect the value of something like
a * (double) (b + c).  Now, assignment to a double *does* scrape off
the excess bits, by definition.  So, the question of whether you are
looking at the LHS of an assignment or the (typecast) RHS as its value
is semantically important in this case.

Any comments?  Have I overlooked something here?