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