[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compiler hints
From: |
Marius Vollmer |
Subject: |
Re: compiler hints |
Date: |
12 Jun 2001 02:24:53 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.102 |
"Dale P. Smith" <address@hidden> writes:
> Wouldn't it be great if there were well-defined hooks at parse time and
> code generation time that you could attach scheme code for whatever you
> wanted? You could build databases that you could do all kinds of
> queries against.
This is from the first issue of "~twaddle" by Tom Lord. It is
available at
ftp://krusty.e-technik.uni-dortmund.de/pub/people/mvo/
Do You Know a Bug When See It?
Application Specific Static Code Checking
for C Programs:
Ctool
ABSTRACT
Most C programs are written in a style that
makes heavy use of statically checkable
invariants. Compilers and similar tools
check *some* of these invariants and warn
programmers when they are violated. But in
other cases, the invariants are too
application specific, or too obscure so that
no generic tool exists which will
automatically checks them.
For example, Systas Scheme is a Scheme
interpreter whose source code declares
"critical sections". During critical
sections, calls to some functions are
prohibited. Outside of critical sections,
calls to other functions are prohibited.
From time to time, bugs are found which
amount to violations of these rules. Is
there an inexpensive way to scan all of the
source for this kind of bug and have some
sense of confidence that no instances of the
bug will be missed?
Application-specific invariants challenge
programmers to build specialized tools that
check for violations. The challenge is to
make appropriate tradeoffs between the
accuracy of static checking, time spent
static checking, and time spent building the
tools for static checking.
Ctool, which is a C parser coupled to a
Scheme interpreter, makes it less expensive
to write more sophisticated static checking
tools. Ctool was built to help debug the
Scheme interpreter it contains. After just a
few days work, ctool has succeeded in finding
long-standing but previously undetected bugs:
a good return on investment.
Static checking is not a panacea. Checking
commonly errs either by not finding real bugs
or by mistakenly finding non-bugs. There is
an accuracy/expense trade-off to static
checking. Ctool doesn't eliminate the trade
off, but it does improve the ratio of
accuracy to expense.
Ctool is such a basic combination of
ingredients that it has many potential uses
even beyond static invariant checking.
- compiler hints, Dirk Herrmann, 2001/06/05
- Re: compiler hints, Martin Grabmueller, 2001/06/05
- Re: compiler hints, Marius Vollmer, 2001/06/09
- Re: compiler hints, Matthias Koeppe, 2001/06/11
- Re: compiler hints, Michael Livshin, 2001/06/11
- Re: compiler hints, thi, 2001/06/11
- Re: compiler hints, Michael Livshin, 2001/06/11
- Re: compiler hints, Dale P. Smith, 2001/06/11
- Re: compiler hints, Rob Browning, 2001/06/11
- Re: compiler hints, Dale P. Smith, 2001/06/11
- Re: compiler hints,
Marius Vollmer <=
- Re: compiler hints, Dale P. Smith, 2001/06/11
- Re: compiler hints, Marius Vollmer, 2001/06/12