Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!snorkelwacker.mit.edu!ai-lab!life!tmb
From: tmb@ai.mit.edu (Thomas M. Breuel)
Newsgroups: comp.lang.c
Subject: Re: Can analysis detect undefined expressions?
Message-ID: <TMB.91Jun19000732@volterra.ai.mit.edu>
Date: 19 Jun 91 04:07:32 GMT
References: <14206.285B7688@stjhmc.fidonet.org> <14394@dog.ee.lbl.gov>
Sender: news@ai.mit.edu
Organization: MIT Artificial Intelligence Lab
Lines: 38
In-reply-to: torek@elf.ee.lbl.gov's message of 18 Jun 91 07:09:53 GMT

In article <14394@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes:
   >>From: ckp@grebyn.com (Checkpoint Technologies)
   >>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 ...

   In article <14206.285B7688@stjhmc.fidonet.org>
   Dave.Harris@f14.n15.z1.fidonet.org (Dave Harris) writes:
   >On the whole, I would say it is NOT possible to contend with every case.

   Indeed, it is fairly easy to show that no compiler can diagnose all
   misuses correctly.

However, a compiler can do better than just detecting problems
with builtins:

(1) it can warn about all potential dependencies on order of
    evaluation. To be useful it requires that all functions
    without side effects are declared as such (see GNU CC/C++):

Thus, this fragment should not generate a warning:

    const double sin(double);

	sin(x)+sin(x)*sin(x)

On the other hand, this fragment should:

    double sin(double);
    ...
	sin(x)+sin(x)*sin(x)

    >>> Warning: potential dependency on order of evaluation

(2) it can generate code to run several versions of the program
    with different orders of evaluation in parallel and detect
    differences in their execution

					Thomas.