Mail Archives: djgpp/2000/02/28/14:02:25
Marcus <mesthlm AT hem DOT passagen DOT se> wrote:
> Sorry but that's my attitude :)
> I do a library and I want a way to check if I can free the memory.
That's not your library's duty. It's the library user's, instead. It's
not too wise to try and protect fellow programmers from their own
errors, as long as the symptoms of those errors are prominent and
unmistakeable enough. For free(), the signature is known by any
competent programmer, and he'll know where to look. You'ld actually be
doing him a misfavour if you tried to hide that error message, IMHO.
> Of course I can ignore that. But how fun would it be with memory
> leaks?
Code with memory leaks is truly bad only in long-running programs on a
multi-processing platform, because there the problem is a sneaky one:
you won't notice it in small tests, but the X11 Server just keeps on
growing and growing, over time, until you cannot bear it anymore and
restart it. For a properly written program on DOS, memory leaks will
either cause no big harm (no other process can be affectly badly by us
using too much memory), or produce an easily detected 'out of memory'
error message from the program.
But the cure of memory errors of either kind (heap corruption or
leaks) is not to try and ignore them. You have to find and fix them,
instead. Setting all invalidated pointers (e.g. after you free() one)
to NULL, immediately, is a good thing to begin with, but by no means
all there is to it.
You really should have a look at YAMD. It's able to find most of these
kinds of error for you, automatically. It will catch free() of
non-malloc()ed pointers, memory leaks, double free()ing, buffer
overruns, and some other types of memory-related errors, all in one
go.
--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -