Re: malloc problem/question in 2.1.3

[Ronald de Man <deman at win dot tue dot nl>]

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 */

> 
> 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. By setting a pointer to NULL you throw away
a reference that has become invalid. By checking a pointer against
NULL before dereferencing it, you make sure the pointer is valid.

> 
> 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.

[snip]

Sorry, this list is not meant for learning C.

> 
> 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.

> 
> 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.

Ronald