Re: malloc problem/question in 2.1.3

[Mike Corbeil <mcorbeil at netrevolution dot com>]

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.

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.

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?

The following are general extras and not directed at any particular
reader.

What's happened to calloc?  The times I've come across malloc and calloc
in books, calloc was or seemed to be considered better or more reliable,
i.e., safer, (definitely in some books), because calloc initializes the
allocated memory to all 0 bits, whereas malloc leaves the initial value
indeterminate.  With calloc, you know what you  have when the allocation
is successful.

I've used calloc, but in all C programs I've done maintenance on, only
malloc was used, by the previous programmers.  Nonetheless, both
functions do the same basic thing, except that calloc is safer.

And, there's the function realloc, at least for programming on Unix, as
per Richard Stevens' book on this topic.  realloc isn't, or probably
isn't, relevant to the individual who began this thread, however it
might be worth mentionning, in passing.  If this function is defined as
required by ANSI, then it'll be available with all ANSI C compilers,
albeit this is only for changing the size of previously allocated
memory, to increase or decrease it.

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

Hopefully, this isn't improper use of this mailing list, because I like
the concept of sharing knowledge.

mike