This is the mail archive of the 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 Tue, Jun 06, 2000 at 01:42:02AM -0400, Mike Corbeil wrote:
> Kaz Kylheku wrote:
> [snipped]
> > > Mike,
> > >
> > > Do you do any XWindows programming???  One of the more
> > > common and hard to track down problems are SIGSEGV's
> > > caused by inadvertently freeing memory that was not previously
> > > allocated.
> >
> > This simply means that you have bungled your logic for initializing
> and
> > destroying subsystems and objects.  This could be the result of poor
> planning
> > at the design stage.
> >
> > > char* ptr = NULL ;
> > >
> > > if (ptr != NULL) {
> > >    free(ptr) ;
> > >    ptr = NULL ;
> > > }
> >
> > This is not necessary. Calling free on a null pointer is permitted by
> > Look it up in your library reference manual.  So you could just write:
> >
> >     free(ptr);
> >     ptr = NULL;
> I thought it was, but it's been a while since I've done any actual
> programming in C; therefore, couldn't recall off of the top of my head.
> A reputable book, one I'ld definitely recommend, "Advanced Programming
> in the Unix Environment", Richard Stevens, 1992, eleventh printing 1996,
> pp 170-171, does not explicitly say that the ptr needs to be verified
> prior to invoking free, however if the ptr (i.e., block of memory
> allocated) was already freed and free is called on the same again, then
> this causes an error; therefore, if the logic is such that this could
> happen, then the text implies that the pointer should be verified,
> first.
> If verifying the pointer is unnecessary, but this code is added, then
> the worst it does is to add a little unnecessary code.  My point in this
> respect is merely that doing this isn't always necessary; however, this
> is not the point I had any real contention with.
> I primarily question the supposed absolute necessity to redefine ptr to
> null immediately after calling free just because free was called to
> deallocate the block of memory assigned to said ptr.  This may sometimes
> be necessary, but not always.

Nobody said that setting the pointer to NULL is absolutely necessary.
There are just some circumstances where this is a convenient and sound
technique to prevent an error like freeing the same block twice.

For example if in an application there are two distinct conditions
that cause the destruction of the same object, then setting the
pointer to this object to NULL after freeing the allocated memory
would signal that the object does not have to be freed once
the other condition occurs. It is just a cheap way to do bookkeeping.
An important condition for the validity of this technique
is that the object is referred to by at most one pointer.


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