|Suggestions for C malloc debugging tool firstname.lastname@example.org (1997-01-07)|
|Re: Suggestions for C malloc debugging tool email@example.com (Laurent Sabarthez) (1997-01-09)|
|Re: Suggestions for C malloc debugging tool firstname.lastname@example.org (1997-01-09)|
|Re: Suggestions for C malloc debugging tool email@example.com (1997-01-09)|
|Re: Suggestions for C malloc debugging tool firstname.lastname@example.org (Philip Lijnzaad) (1997-01-12)|
|Re: Suggestions for C malloc debugging tool email@example.com (T.E.Dickey) (1997-01-12)|
|Re: Suggestions for C malloc debugging tool firstname.lastname@example.org (1997-01-12)|
|[4 later articles]|
|From:||email@example.com (Joerg Schoen )|
|Date:||7 Jan 1997 12:36:04 -0500|
|Keywords:||C, debug, storage, comment|
Hello out there!
I would like to get some comments about the following idea: A lot of
trouble in developing C code results from bad memory accesses through
invalid or uninitialized pointers, through subscripts out of range and
so on. Unfortunately these errors usually show up much later and are
hard to track down.
Now suggest a debugging tool as follows: A "preprocessor" that
processes C to C and inserts a validity check prior to every memory
access in the code. Obtaining the valid range of pointer variables is
done in two steps. First, generate for every pointer variable
additional ones that mark the valid range of access for the
pointer. Second, when assigning pointer variables (to other pointers,
or to the result of a "malloc" call for example), update the range
Of course, this has to be generalized appropriately for multiple
pointer variables (which is a little bit tricky and not discussed here
to save space). Additionally, calls to subroutines with pointer
arguments have to be "patched" to pass the ranges of the pointers as
well. To support canned routines (from the standard library for
example), certain "#pragma" lines aid in dealing with canned
routines. These pragmas can also be used directly to "support" the
parser when encountering complicated assignments, and are otherwise
ignored when compiling the program.
Some technical remarks: The advantage of implementing the project as
a C to C parser is that the tool will be largely machine independent
and does not have to deal with object code, the machine's assembler
code etc. The program itself will be pure ANSI-C. For some internal
reasons not discussed here the program has to do the standard
C-preprocessing as well. Therefore the program has to know the
predefined symbols of a system and to support some internally used
compiler extensions (which appear usually in <stdarg.h> header files
and other places as well). This is currently solved by employing some
very *general* extensions to the parser itself which allows one to
circumvent actually most of the local's compiler stuff.
I have mentioned the more technical stuff to show how far this
project actually has gone. In fact, the current state is a combined
ANSI- preprocessor and parser that runs on 7 different platforms, and
a lot of ideas how to get the desired behaviour of the final tool.
However, some questions of usefulness remain. First of all, does
something like that already exist? I know "Purify", even though I have
not used it a lot. In my opinion, "Purify" is more machine dependent
and has of course much more features. Second, I am not sure if the
tool finally will be useful when working as discussed above. Is it
able to cope with 90% of the usual allocation stuff in C programs? I
guess no one will use a tool that requires a lot of user intervention
to do something useful.
Any hints, suggestions welcome.
Theoretische Chemie Phone: 06221-545220
Physikalisch-Chemisches Institut Fax: 06221-545221
Im Neuenheimer Feld 253
[This sounds awfully familiar, I'm sure it's been done many times before.
It's a good idea, would be interesting to hear experience re how well it
works in practice. -John]
Return to the
Search the comp.compilers archives again.