Can analysis detect undefined expressions?

Dave Harris Dave.Harris at f14.n15.z1.fidonet.org
Tue Jun 25 22:59:56 AEST 1991


In a message of <Jun 21 17:44>, Arnold Geels (1:114/15) writes: 
 >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!

I am not questioning that undefined statements should not be used.  They most 
definately should NOT be used.  I am just rambling about what I would do with 
a compiler that would have *ADDITIONAL* logic to make your code yield an 
unexpected result or some type of debug value like -9999.  I should narrow the 
term "unexpeceted" down to any given machine as its evidently different on 
multi-processor machines (learn something new every day).  Pretty moot to talk 
about since only the worst fool would make their compiler this way instead of 
printing out a warning.

Dave Harris.
 


 

--  
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!15!14!Dave.Harris
Internet: Dave.Harris at f14.n15.z1.fidonet.org



More information about the Comp.lang.c mailing list