Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site nlm-vax.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-tgr!nlm-mcs!nlm-vax!lef
From: lef@nlm-vax.ARPA (Larry Fitzpatrick)
Newsgroups: net.unix,net.unix-wizards,net.lang.c
Subject: debugging strategies
Message-ID: <556@nlm-vax.ARPA>
Date: Thu, 26-Sep-85 12:53:02 EDT
Article-I.D.: nlm-vax.556
Posted: Thu Sep 26 12:53:02 1985
Date-Received: Sat, 28-Sep-85 08:14:59 EDT
Distribution: net
Organization: NLM/LHNCBC, Bethesda, Md.
Lines: 28
Xref: watmath net.unix:5732 net.unix-wizards:15009 net.lang.c:6537

I am interested in different approaches that C programmers use (used)
to trace bugs having to do with errant pointers in memory.

Most of us have probably put together a goodly-sized program that
allocates and frees memory for the management of a variety of in-memory
data structures. Programming errors related to the accessing and
management of this memory (mostly:
	1) reference through uninitialized or dangling pointers
	2) reference through a pointer past the bounds of the
	   data structure it is supposed to point to
	3) garbage accumulation)
can be very difficult to detect since the point of detection/damage
can be far removed from the point of infraction.

What I would like to know is what conventions/strategies/techniques
has anyone out there found useful for
	1) preventing these types of errors or
	2) finding them when they occur.

You may mail responses to me and I will summarize to the net.

Thanks
	fitz
	lef@nlm-vax.arpa

	L Fitzpatrick
	National Library of Medicine
	Bethesda, MD 20894


Brought to you by Super Global Mega Corp .com