This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
Re: malloc problem/question in 2.1.3
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