From: Hans-Bernhard Broeker Newsgroups: comp.os.msdos.djgpp Subject: Re: Prevent crash on free() Date: 28 Feb 2000 17:57:12 GMT Organization: Aachen University of Technology (RWTH) Lines: 37 Message-ID: <89ecto$jum$1@nets3.rz.RWTH-Aachen.DE> References: <89e5e3$8g1$1 AT cubacola DOT tninet DOT se> <89e72m$hpt$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> <89e7oq$cmv$1 AT cubacola DOT tninet DOT se> NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de X-Trace: nets3.rz.RWTH-Aachen.DE 951760632 20438 137.226.32.75 (28 Feb 2000 17:57:12 GMT) X-Complaints-To: abuse AT rwth-aachen DOT de NNTP-Posting-Date: 28 Feb 2000 17:57:12 GMT User-Agent: tin/1.4-19991113 ("No Labels") (UNIX) (Linux/2.0.0 (i586)) Originator: broeker@ To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Marcus 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.