guile-devel
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]