Can analysis detect undefined expressions?
Will Crowder
willcr at bud.sos.ivy.isc.com
Fri Jun 14 09:19:24 AEST 1991
In article <1991Jun13.015548.24724 at grebyn.com>, ckp at grebyn.com
(Checkpoint Technologies) writes:
|> The subject line is not very good. Let me explain what I want.
|>
|> Some expressions in C are undefined, because of expression reordering and
|> side effects. A recent (ongoing?) thread discussed the possible different
|> interpretations of if ((i=1) == (i=2)), and there are other examples like
|> i = i++ + i++, and so on.
|> I'd like to know if there has been any attempt to diagnose such undefined
|> expressions. It seems like an exceedingly difficult thing to do,
|> especially considering aliasing and possible side effects of functions.
I'm not sure if it has been proven impossible, and indeed, trivial and
obvious violations like "i = i++ + i++" are easy to spot. However,
how would you deal with the case of:
i = (*p)++ + (*q)++;
I mean, this statement is perfectly legal and its value defined if
p != q. However, if p == q, then you're once again in deep yogurt as you're
modifying the same object twice without an intervening sequence point.
I don't know statistics well enough to put this as eloquently as I'd like,
but:
Determining at compile time of p could ever be equal to q would require
exhaustive code path analysis, and this analysis has been shown to take
longer than the estimated remaining lifespan of the galaxy for anything
over a few lines. (I can't remember that great quote I heard about it,
or I'd put it in my .sig.)
Will
--------------------------------------------------------------------------------
Will Crowder, MTS | "Any airplane you can't roll ain't no
(willcr at ivy.isc.com) | damn good!"
INTERACTIVE Systems Corp. | -- Tex Johnson
More information about the Comp.lang.c
mailing list