Can analysis detect undefined expressions?

[Arnold Geels]

In comp.lang.c you write:
>>      (j = ((i=1) == (i=2))) == (j = ((i=3) == (i=4)))

>Not arguing that the result is undefined as you say.  But....
>I for one would quickly scrap any compiler that went to the additional work of 
>embedding code to yield a value of anything other than 1,2,3 or 4 for i.  It 
>would mean the compiler would have to detect the undefined statement first 
>before it could even do this. 

You're missing the point.  The "undefined" rule was not invented to
tease the users of C, but to please the compiler writers!  Of course
nobody is going to write a compiler that deliberately starts up a game
of rogue if compiling this expression.  But if on some future computer
the {natural, fastest, best, only} way to code expressions leads to i
getting set to something unequal to 1,2,3, or 4, then surely this is
the way this expression will be coded!

>It would be just one more thing that could go accidently wrong 
>on perfectly good code.

"perfectly good code" is NOT equal to "code that works now and that I would
very much like to continue working in the future"...  

>I would really like to see an example of code accomplishing completely 
>unexpected behavior as in setting i equal to 5. 

("Unexpected" by whom?)

-- fantasy mode ON --

Suppose we have, in the future, a massively parallel computer that
works with one processor for each variable.  Whenever an assignment is
made to a variable, you send a message to the appropriate processor.
When building this computer, the engineers found out that sometimes two
or more assignment messages would arrive at the same node at the same
time.  They found out that the fastest solution was to ignore BOTH
messages, i.e. no assignment is done at all.  In the above statement,
objects "1", "2", "3", and "4" all send a message to i at the same
time...  All messages cancel out,  and i keeps its old value.  Voila.

-- fantasy mode OFF --

>There probably isn't a 
>compiler around that would do it because it would be extraneous work and risky 
>to boot.

It probably isn't around NOW, but it could be around in the future...  Do
YOU know what the future architectures are like?  And do you want your
programs to work on them?

Arno1d.