Re: malloc problem/question in 2.1.3

[Mike Corbeil <mcorbeil at netrevolution dot com>]

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.

Also, in all of the C programming and maintenance I've done, I have never
seen anyone do this and it's also not found in any reputable books on C.

What you're doing when freeing the pointer is saying that it's no longer
needed.  Point final.

The bottom line is logic and it's not logical to reinit the pointer to null
immediately after calling free on the pointer, unless the reinit is related
to something else, and this condition doesn't always exist or apply.

Ask yourself what use will be made of the pointer.  Because it's been freed,
no use will be made of the pointer, at least not until it's to be used again
and this is basically unrelated to the call to free.


> >
> > 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?
> >
> > That sounds like strange use of a pointer associated with malloc.
> > Without being certain of what was meant, I would typically define the
> > pointer to null just prior to invoking malloc for the pointer, or at the
> > beginning of a block of code.  Such a pointer typically isn't used after
> > freed and is therefore only used in the scope of code between the calls
> > to malloc and free, conceptually.  If this is strictly followed, then
> > there's no point in redefining or re-initializing such a pointer
> > immediately after the call to free, unless the next step is to reinvoke
> > malloc for the pointer.
> >
> > free is called because a pointer is no longer needed, or is needed for
> > something else.  When speaking of freeing a pointer, what follows
> > shouldn't matter, because it's logically separate from the call to
> > free.  free is also often invoked as the last statement of a function.
>
> You don't free a pointer. You free the memory block that is pointed
> at by the pointer.

Useless word play.  I know and knew that it was the memory block assigned to
the pointer which was being freed, but it's much quicker to say "free the
pointer" than "free the memory block assigned to the pointer"; three words as
opposed to eight.

Rare is an English speaking C programmer who wouldn't understand what's meant
and I only work in English and French, and this mailing list is in English.
I believe most people using this mailing list probably know C well enough to
know what I meant.

> By setting a pointer to NULL you throw away
> a reference that has become invalid.

You quibble about others being imprecise in their wording, but then do the
same yourself.  If you're going to quibble about others to show off, then
this isn't a good idea.  If you're going to quibble for other reasons, then
at least be integral, i.e., consistent.

You don't throw away anything, to be as precise as you appear to like to be.


> By checking a pointer against
> NULL before dereferencing it, you make sure the pointer is valid.

Trivial to understand; it's an elementary point.

> >
> > I don't have the time to investigate this in detail, and am not sure
> > what you meant, however a wrapper could possibly also be reusable,
> > stored in a library for use by anyone wishing to use that lib.
> >
> > Did I get lost in or misunderstand this?
>
> Yes.

Obviously I didn't, but you did.

> [snip]
>
> Sorry, this list is not meant for learning C.

So, why are you continuing?  Why are you saying this isn't for learning C,
but you like to show off about knowledge of C in trivial, insignificant ways?

> >
> > However, if this thread wasn't begun by someone working on a compiler,
> > but instead developing an application, then another language might be
> > more suitable.  If the work could be done in Perl, then the problem with
> > free wouldn't have come up.
> >
> > Although this doesn't necessarily mean that Perl is more suitable,
> > knowing several languages and tools does equip a person with the ability
> > to provide better solutions.
> >
> > If junior, then don't pay too much attention to the above paragraph,
> > that is, don't get discouraged; it all comes with time and experience.
> >
> > As you can witness, I do and will not use the glibc help mailing lists
> > to fanatically support C and condemn all other languages, other than C++
> > and Objective-C of course (extensions of C).  I prefer to try to use the
> > most suitable tools, albeit there's always room for reasonability in
> > life (if benefit of a language I don't know is minute, then time usually
> > takes priority, forcibly or otherwise).
>
> This list is not a suitable tool for these discussions, I'm afraid.

Don't continue them then.

However, there's nothing wrong with using these lists for such discussions,
if the Subject title of the thread is sufficiently clear for others to know
what's being discussed.  If you're that inflexible in life, then you're
written off as petty.

> >
> > Hopefully, this isn't improper use of this mailing list, because I like
> > the concept of sharing knowledge.
> >
>
> Sorry, it is. Please take a look at the comp.lang.c newsgroup instead.

I don't need it and there's a good or very fair chance I've known C longer
than yourself, and you haven't taught me anything, just to make sure you
understand who you're trying to teach.

Before reading mail, read the subject title.  If the subject isn't pertinent
or of interest to you, then simply delete and move on.

That's the flexible approach to LIFE.  Learn to be flexible, or be written
off as petty.

mike


>
>
> Ronald