Re: malloc problem/question in 2.1.3

[Mike Corbeil <mcorbeil at netrevolution dot com>]

Ronald de Man wrote:

> On Sat, Jun 03, 2000 at 07:13:51PM -0400, Mike Corbeil wrote:
> > Ronald de Man wrote:
> >
> > > On Fri, Jun 02, 2000 at 07:45:34PM -0400, Mike Corbeil wrote:
> > > > Wolfgang Sourdeau wrote:
> > > >
> > > > >     Mike> As a short aside, I think that this could be checked for in
> > > > >     Mike> Perl using "defined" (e.g., if defined $var ...), however C
> > > > >     Mike> is a compiled language and I don't think there's any such
> > > > >     Mike> functionality, not afaik anyway.
> > > > >
> > > > > One could implement this by writing a wrapper for malloc and free
> > > > > which would do the accounting. Another way to do that is to put a
> > > > > pointer to NULL directly after it is freed and it is even easier. Be
> > > > > careful though to make this coherent with the whole code.
> > > >
> > > > If a job must be done in C and such functionality is desired, then a
> > > > wrapper is probably an acceptable solution.  I've used and created
> > > > wrappers before, however thought the programmer wanted built-in
> > > > functionality, and wrappers are an elementary concept, but not
> > > > built-ins.  (Wrapping is actually, conceptually, inherent in all
> > > > programs using functions or procedures, and a program itself is a
> > > > wrapper, albeit neither is the kind of wrapper Wolfgang referred to.)  A
> > > > wrapper is certainly an easy approach.
> > > >
> > > > However, I'm not sure what is meant by "put a pointer to NULL" after it
> > > > is freed.
> > >
> > > char *ptr = (char *)malloc(100);
> > >
> > > /* use the 100 allocated bytes */
> > >
> > > free(ptr);
> > > ptr = NULL;    /* put ptr to NULL */
> >
> > I assumed this was what you meant, but this is unnecessary, unless ptr is
> > going to be used again.  One simple case to show how this is, simply is that
> > free is often called at the end of functions.  However, even when called
> > before the end of a function, there's no logical reason to do this, because
> > the pointer was just freed.
>
> 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.


> This is a way to improve robustness
> of the program. (On the other hand it might hide bugs.)

Should have no impact wrt improving robustness.  If we did this for every piece
of code where such a concept could possibly or potentially apply, then yuck is
about all I could think of.  We need more reliability than that, imo.

> This discussion was about the perceived lack of robustness in free().

It's not really only perceived; it's real, but it's also known and a known is
always better than an unknown.  It's been known for longer than I've known C,
since June 89 (I had merely forgotten the reason); however, no expert has ever
suggested that a free'd pointer be immediately redefined to null, for robustness
or any other reason, and I agree with them in excluding this nonsense as well as
believe that it's nonsense, usually anyway, except when necessary and only
context will be the decisive factor.

> For example, programs tend to crash when free()ing memory twice.

Just don't do that.  Proper logic should preclude this, I believe.  Otoh, perhaps
it would be proper logic, but we haven't been provided with any real world
examples, so far.

> Wolfgang pointed out that one common way to prevent this type of
> crashes, is to set a pointer to NULL when it is no longer needed.
>

Should not need to be done, at least not in well designed and written programs.
Again, there may be examples where this is indeed applicable, however these
examples haven't been mentioned.   We need applicable, real world, examples; or
at least I do, to be convinced.

> My example could have been clearer:
>
> if (ptr != NULL) {      /* is this a valid reference? */
>   free(ptr);            /* then we can free the memory */
>   ptr = NULL;
> }

Comments are unnecessary for me, because I know C; however, the last statement is
or at least should be unnecessary.  If it's necessary, then this indicates that
there's another problem and it should be resolved by other means, like clean
programming; or, it's an application-specific need, in which case what's the
example would be my question.

> If the memory block had already been freed (so by convention, ptr had
> been set to NULL), then this check makes sure it is not freed for a
> second time.

That's only wrt the 'if' check, which isn't at all what I was questioning.  This
I have no question about wrt C, because it's basically imposed by or in C.

It's not technically or strictly valid wrt redefining the ptr to null, which is
what I was questioning.  I might initialize a ptr to null prior to calling malloc
or calloc, or where a ptr is declared (where I always init to null, or what ever
the default value is to be), however to say that this should be done every time
free has been called is not necessary, afaik.

In the case of the if (in C), the programmer is doing what free should do;
however, historically, there was a performance impact (had forgotten the reason,
but knew there was one); therefore, free wasn't written to check for this
condition.  This problem or caveat, however, has surely disappeared with the dawn
of more powerful CPUs, and ANSI isn't robust, except at a superficial level (ANSI
sucks, in this sense, #$#$#$#$!!!!!, as I'm sure many would say, more or less).

Redefining ptr to null is a very separate, distinct, concept, because it really
has nothing to do with free, except that free doesn't make the redefinition.
Although free could do this, there's really no reason for it to do so and there
are cases where this would be unnecessary overhead, technically and logically.

Checking the ptr before calling free is kind of a patch, as is redefining ptr to
null, but only the first or former patch is logically valid, in a strict sense,
but only because it's imposed by C or $#$!@#$!@#!!!! ANSI.


> >
> > > >
> > > > Do you mean to redefine the pointer as the null string, as it would be
> > > > done in the initialization of a pointer, and if yes, then why would one
> > > > want to do this immediately after calling free, when free is supposed to
> > > > free the memory previously reserved for the pointer, after which such a
> > > > pointer typically isn't used, at least not until malloc is to be invoked
> > > > again for the pointer?
>
> [I am sorry to have disturbed you, but reading the above did give me
> the impression that you were mixing up pointers with the memory
> blocks pointed at by pointers.]

No problem.  If you honestly misinterpreted my knowledge of C, then that's
human(e), and because C has been ported to most platforms, I'm not expert in all
respects.  I wanted to make sure people understood that I'm not new to C;
programmed with C since 89, took a very good course on C, and have read several
good books from industry reknowned experts on C, over the years, as well as
having developed in C and maintained an ample number of C programs.

This, however, does not mean that I'm absolutely correct.  I'm not GOD.  It's
possible that redefining the pointer to null is necessary in some cases, however
I've never come across any such cases, and no examples have been provided, here,
so far.

For example, in some contexts it's crucial or important to check the result of
malloc, but in others, like VAX/VMS, it's not necessary, or at least not
according to some people who developed mission critical systems in C on this
platform; people possessing graduate degrees in CS.  I believe that it is
unnecessary in VAX/VMS, but it is definitely a strong plus or even necessary in
MS, or at least MS DOS.  For Unix I'm not sure, however regardless what OS I
program in, I always check the result of malloc, even if only for potential
portability.


> Note that on the internet it is common practice to refer
> people to more appropriate forums. This list is intended for
> discussion of the use of the GNU C library.

I understand that.  However, I try to be flexible and believe that there's plenty
of room on the internet for this.

As long as meaningful Subject titles are used, then I'm happy.  I have no problem
reading a subject title and deleting the mail if I'm not interested; letting
others get on with their business while I get on with mine; an independent minded
squirt I am.  Besides, it's virtually imposssible to monitor the internet to 100%
exactness.

I'm exacting wrt programming computers, because they only do what they're
instructed to do, but when it comes to humans, flexibility is fine with me.   You
have plenty of room with me and I also firmly, thoroughly, believe in sharing
knowledge, a grand concept imo.

In this case, the original question was accepted and once that happens, I let the
river flow, without trying to impede it, because it encourages learning, which
all humans benefit from, eventually, one way or another, etc.   The subject title
is what I rely on.

Also, there are too many truly important contentions and disagreements in this
world for me to waste energy needlessly.

Thank you.  I appreciate your reply, cool and calm, merci beaucoup.

If I'm still off on usage, then please feel free to reply.  I'll consider input,
even if the above kind of flexiblity is the way I prefer to look at life.  Maybe
I need to be cemented, a little, but I like flexible.

Mike