This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
Re: malloc problem/question in 2.1.3
- To: glibc-linux at ricardo dot ecn dot wfu dot edu
- Subject: Re: malloc problem/question in 2.1.3
- From: Kaz Kylheku <kaz at ashi dot footprints dot net>
- Date: Mon, 5 Jun 2000 07:02:12 -0700 (PDT)
- Reply-To: glibc-linux at ricardo dot ecn dot wfu dot edu
On Mon, 5 Jun 2000, Mike Corbeil wrote:
> > The point is that one can now check whether the pointer is still valid
> > by testing it against the NULL value.
>
> I understood that, but there's no logical reason for it, except like you say to
> potentially hide bugs, or poor C programming. You probably won't find a good,
> authoritative, book on programming in C which instructs people to redefine the
> pointer to null after the pointer's been freed, or at least I've never come
> across such a book.
>
> Perhaps there are programs in which this would be applicable, however no one has
> mentioned any examples, yet.
It makes sense from time to time when the program maintains just one pointer to
some dynamic object, and there is a need to test whether or not that object is
present, because it has a short, intermittent lifetime relative to the
containing object. In other words, testing the pointer for null is incorporated
into the logic.
Otherwise, it's just a kludge. The programmer is saying, ``I'm destroying this
object, but I might continue to try to use it, so just in case, I'm going to
null out what is hopefully the only pointer to it''. However, continuing to use
the pointer is a bug whether that pointer is indeterminate or null. So all
that this practice does is substitute a more predictable failure for a less
predictable one rather than fix the bug.