This is the mail archive of the glibc-linux@ricardo.ecn.wfu.edu mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: malloc problem/question in 2.1.3


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]