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