malloc and free

[Joris Adriaenssens]

This is my first posting, please excuse me if it is off-topic.

I'm learning to program in C. It's been almost ten years I've been
programming and a lot of things have changed apparently.

I understand from other postings that casting a result from malloc
isn't good. In the past I have always been casting the malloc. I
think it was even necessary. (But that's a long time ago, I hadn't
heard of a standard for C these days). Was it really necessary or did
we do it only to silence the warnings ? (cfr. FAQ q7.7 - I can't
look in the manuals from these days : I don't have them any longer)
When I use malloc for the allocation of a small piece of memory, e.g.
a single node of a linked list, I use 'free' to release the memory
afterwards. When using 'free', I don't have to worry about the size
of the allocated block the pointer is pointing to.
Is it the operating-system that is responsible to remember the size of
that piece of memory ?
In that case, when I build a large linked-list by allocating memory
for each node, I get a lot of overhead in the operating system. Is
this right ? or is this implementation-specific or operating-system
specific ? (FAQ q7.26 says that the implementation 'remembers' the
size. Does this mean that every implementation may do it in his own
way ? )
If the computer has to remember for each single allocation the size of
the allocated block, is it better than, to allocate a bigger piece of
memory and keep track of the use of it within the program, when I try
to create a linked-list or a binary tree or something like that ?

Thank you.
Joris Adriaenssens

[Barry Schwarz]

On 6 Sep 2004 08:39:00 -0700, jo************* ***@hotmail.com (Joris
Adriaenssens) wrote:

This is my first posting, please excuse me if it is off-topic.

I'm learning to program in C. It's been almost ten years I've been
programming and a lot of things have changed apparently.

I understand from other postings that casting a result from malloc
isn't good. In the past I have always been casting the malloc. I
think it was even necessary. (But that's a long time ago, I hadn't
heard of a standard for C these days). Was it really necessary or did
we do it only to silence the warnings ? (cfr. FAQ q7.7 - I can't
look in the manuals from these days : I don't have them any longer)
Things change over time. The cast became unnecessary when malloc
started returning void*.

Using a cast to silence a warning is a common but not foolproof
technique. The compiler is free to give any (superfluous) diagnostic
it likes as long as it correctly compiles a conforming program.


When I use malloc for the allocation of a small piece of memory, e.g.
a single node of a linked list, I use 'free' to release the memory
afterwards. When using 'free', I don't have to worry about the size
of the allocated block the pointer is pointing to.
Is it the operating-system that is responsible to remember the size of
that piece of memory ?
It is an implementation responsibility. Whether that falls on the
operating system of the C run-time library is an implementation issue.
In that case, when I build a large linked-list by allocating memory
for each node, I get a lot of overhead in the operating system. Is
"lot" is a matter of opinion. Some operating systems may do this so
efficiently that the amount of overhead is not unacceptable *to you*.
this right ? or is this implementation-specific or operating-system
specific ? (FAQ q7.26 says that the implementation 'remembers' the
size. Does this mean that every implementation may do it in his own
way ? )
Yes
If the computer has to remember for each single allocation the size of
the allocated block, is it better than, to allocate a bigger piece of
memory and keep track of the use of it within the program, when I try
to create a linked-list or a binary tree or something like that ?

"better" is also a matter of opinion. It also probably depends on the
quality of implementation for your system (which is determined by both
the run-time library and the operating system).

In a system with a "good" malloc, individual calls for each node may
be preferable (less code to write, easier to maintain, etc). In a
system with a "poor" malloc, a single call for a large area which you
subdivide yourself may be preferable (program will run noticeably
faster, less fragmentation of memory, etc).
<<Remove the del for email>>

[Ben Pfaff]

jo************* ***@hotmail.com (Joris Adriaenssens) writes:

I understand from other postings that casting a result from malloc
isn't good. In the past I have always been casting the malloc. I
think it was even necessary. (But that's a long time ago, I hadn't
heard of a standard for C these days). Was it really necessary or did
we do it only to silence the warnings ? (cfr. FAQ q7.7 - I can't
look in the manuals from these days : I don't have them any longer)
It was necessary with pre-ANSI compilers. Casting the result of
malloc() is not necessary with any ANSI C89 or later compliant
compiler. However, you'll normally get a warning if you forget
to #include <stdlib.h>. In that case, the correct fix is to add
the #include, not to add a cast.
When I use malloc for the allocation of a small piece of memory, e.g.
a single node of a linked list, I use 'free' to release the memory
afterwards. When using 'free', I don't have to worry about the size
of the allocated block the pointer is pointing to.
Is it the operating-system that is responsible to remember the size of
that piece of memory ?
Somebody has to (more or less). It may be a library linked into
your program or it may be the operating system.
In that case, when I build a large linked-list by allocating memory
for each node, I get a lot of overhead in the operating system. Is
this right ? or is this implementation-specific or operating-system
specific ?
Yes, both.
(FAQ q7.26 says that the implementation 'remembers' the size.
Does this mean that every implementation may do it in his own
way ? )
Yes.
If the computer has to remember for each single allocation the
size of the allocated block, is it better than, to allocate a
bigger piece of memory and keep track of the use of it within
the program, when I try to create a linked-list or a binary
tree or something like that ?

If you think you can do the tracking with lower overhead than the
implementation, that can be a perfectly good idea.
--
"C has its problems, but a language designed from scratch would have some too,
and we know C's problems."
--Bjarne Stroustrup

[Malcolm]

"Joris Adriaenssens" <jo************ ****@hotmail.co m> wrote

I understand from other postings that casting a result from malloc
isn't good. In the past I have always been casting the malloc. I
think it was even necessary. (But that's a long time ago, I hadn't
heard of a standard for C these days). Was it really necessary or did
we do it only to silence the warnings ? (cfr. FAQ q7.7 - I can't
look in the manuals from these days : I don't have them any longer)
C implicitly casts a void * to another type of pointer. C++ does not. The
main reason for casting the return from malloc() is to allow the code to
compile under C++. This may be necessary or even undesireable, depending on
the environment in which you work. .
Is it the operating-system that is responsible to remember the size of
that piece of memory ?
The operating system just has to allocate and free memory on demand. In
practise it usually does this by storing the size of the block in the memory
immediately before the pointer returned from malloc(). However a weird and
wonderful system may do things differently.
If the computer has to remember for each single allocation the size of
the allocated block, is it better than, to allocate a bigger piece of
memory and keep track of the use of it within the program, when I try
to create a linked-list or a binary tree or something like that ?

The best rule is to use malloc() to allocate your nodes. Then if the program
runs too slowly, you can see if you can optimise. A fixed-block allocator
can be written much more efficiently than one that has to deal with any
size. Unfortunatley the meory it uses cannot normally be recycled for
general use, so it is not a panacea.

[Jack Klein]

On Mon, 6 Sep 2004 19:22:56 +0100, "Malcolm"
<ma*****@55bank .freeserve.co.u k> wrote in comp.lang.c:

"Joris Adriaenssens" <jo************ ****@hotmail.co m> wrote

I understand from other postings that casting a result from malloc
isn't good. In the past I have always been casting the malloc. I
think it was even necessary. (But that's a long time ago, I hadn't
heard of a standard for C these days). Was it really necessary or did
we do it only to silence the warnings ? (cfr. FAQ q7.7 - I can't
look in the manuals from these days : I don't have them any longer)

C implicitly casts a void * to another type of pointer. C++ does not. The

^^^^^^^^^^^^^^^ ^

No, it doesn't. C automatically converts a pointer to void to any
type of object pointer. There is no such thing as an "implicit cast"
in C, as a cast is defined as an "explicit conversion".

And there is no conversion from pointer to void to pointer to any type
of function. Only to pointer to other object types.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[RCollins]

Jack Klein wrote:

On Mon, 6 Sep 2004 19:22:56 +0100, "Malcolm"
<ma*****@55bank .freeserve.co.u k> wrote in comp.lang.c:

"Joris Adriaenssens" <jo************ ****@hotmail.co m> wrote

I understand from other postings that casting a result from malloc
isn't good. In the past I have always been casting the malloc. I
think it was even necessary. (But that's a long time ago, I hadn't
heard of a standard for C these days). Was it really necessary or did
we do it only to silence the warnings ? (cfr. FAQ q7.7 - I can't
look in the manuals from these days : I don't have them any longer)

C implicitly casts a void * to another type of pointer. C++ does not. The

^^^^^^^^^^^^^^^ ^

No, it doesn't. C automatically converts a pointer to void to any

^^^^^^^^^^^^^^^ ^^^^^^^ type of object pointer. There is no such thing as an "implicit cast"
in C, as a cast is defined as an "explicit conversion". ^^^^^^^^^^^^^^^ ^^^^
And there is no conversion from pointer to void to pointer to any type
of function. Only to pointer to other object types.

I don't understand this. As I read it, you are saying that C performs
an "automatic conversion" of the void *, but does not do an "explicit
conversion" (see underlined sections, above).

I understand that you are talking strictly about a cast operation; but
it seems to me that the compiler must *explicitly* convert the "void *"
to a "struct foo *" (for example).

What is the difference? Most important, what is the difference to the
*programmer* ?

--
Ron Collins
Raytheon Air Defense/RTSC/BCS

[Ben Pfaff]

RCollins <rc***@nospam.t heriver.com> writes:

I don't understand this. As I read it, you are saying that C performs
an "automatic conversion" of the void *, but does not do an "explicit
conversion" (see underlined sections, above).

I understand that you are talking strictly about a cast operation; but
it seems to me that the compiler must *explicitly* convert the "void *"
to a "struct foo *" (for example).

What is the difference? Most important, what is the difference to the
*programmer* ?

An explicit conversion is one that you explicitly tell the
implementation to do, i.e. a cast. An automatic or implicit
conversion is done by the implementation without an explicit
request. The implementation has to do the same work regardless
of whether a conversion is implicit or explicit. The difference
is in the syntax, not the semantics.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Jack Klein]

On 7 Sep 2004 01:03:15 GMT, RCollins <rc***@nospam.t heriver.com> wrote
in comp.lang.c:

Jack Klein wrote:

On Mon, 6 Sep 2004 19:22:56 +0100, "Malcolm"
<ma*****@55bank .freeserve.co.u k> wrote in comp.lang.c:

"Joris Adriaenssens" <jo************ ****@hotmail.co m> wrote

I understand from other postings that casting a result from malloc
isn't good. In the past I have always been casting the malloc. I
think it was even necessary. (But that's a long time ago, I hadn't
heard of a standard for C these days). Was it really necessary or did
we do it only to silence the warnings ? (cfr. FAQ q7.7 - I can't
look in the manuals from these days : I don't have them any longer)
C implicitly casts a void * to another type of pointer. C++ does not. The

^^^^^^^^^^^^^^^ ^

No, it doesn't. C automatically converts a pointer to void to any

^^^^^^^^^^^^^^^ ^^^^^^^

type of object pointer. There is no such thing as an "implicit cast"
in C, as a cast is defined as an "explicit conversion".

^^^^^^^^^^^^^^^ ^^^^

And there is no conversion from pointer to void to pointer to any type
of function. Only to pointer to other object types.

I don't understand this. As I read it, you are saying that C performs
an "automatic conversion" of the void *, but does not do an "explicit
conversion" (see underlined sections, above).

I understand that you are talking strictly about a cast operation; but
it seems to me that the compiler must *explicitly* convert the "void *"
to a "struct foo *" (for example).

What is the difference? Most important, what is the difference to the
*programmer* ?

From dictionary.com, the first entry for each respective word:

implicit: Implied or understood though not directly expressed.

explicit: Fully and clearly expressed; leaving nothing implied.

Now let's look at an implicit conversion in C:

int i;
char ch = 'a';
i = ch; /* implicit conversion of char to int */

And an explicit conversion:

int i;
char ch = 'a';
i = (int)ch;

See how the first is "implied or understood but not directly
expressed" and the second is "fully and clearly expressed; leaving
nothing implied"?

The use of a cast operator is an explicit directive to the compiler to
perform a conversion. In some cases, as in the two little examples
above, the cast specifies a conversion that would be implicit anyway.
In that case, it is just what I call a "redundant cast", which is
usually but not always just useless noise.

Consider another case, assume <limits.h> is included:

int i;
double d = (double)INT_MAX + 10.0;
i = d; /* implicit automatic conversion */
i = (int)d; /* explicit "redundant" cast */

In the second example, the redundant cast gains you absolutely
nothing. d contains a value outside the range of an unsigned int, so
the implicit conversion caused by the assignment produces undefined
behavior. The explicit cast causes exactly the same undefined
behavior, so it buys nothing at all.

There are some cases where you must use a cast to cause an explicit
conversion because there is no automatic conversion, for example
between any two types of object pointers if neither is a pointer to
void:

int i = 12;
int *ip = &i; /* extra variable for documentation */
char *cp = ip; /* diagnostic required */
char *cp = (char *)ip; /* OK */

And there are some conversions that are not allowed even with a cast:

struct s1 { int i1; double d2; };
struct s2 { double d2; int i2; };

struct s1 { 3, 42.0 };
struct s2;
s2 = s1;
s2 = (struct st)si;

And as for my assertion that a cast is an explicit conversion, rather
than an automatic conversion being a implicit cast, that comes from
the wording of the C standard itself:

6.3 Conversions

1 Several operators convert operand values from one type to another
automatically. This subclause specifies the result required from such
an implicit conversion, as well as those that result from a cast
operation (an explicit conversion). The list in 6.3.1.8 summarizes
the conversions performed by most ordinary operators; it is
supplemented as required by the discussion of each operator in 6.5.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Joris Adriaenssens]

Ben Pfaff <bl*@cs.stanfor d.edu> wrote in message news:<87******* *****@benpfaff. org>...

I understand from other postings that casting a result from malloc
isn't good. In the past I have always been casting the malloc. I
think it was even necessary. (But that's a long time ago, I hadn't
heard of a standard for C these days). Was it really necessary or did
we do it only to silence the warnings ? (cfr. FAQ q7.7 - I can't
look in the manuals from these days : I don't have them any longer)

It was necessary with pre-ANSI compilers. Casting the result of
malloc() is not necessary with any ANSI C89 or later compliant
compiler. However, you'll normally get a warning if you forget
to #include <stdlib.h>. In that case, the correct fix is to add
the #include, not to add a cast.

....

Thanks for the fast replies. They are very clear to me.

[Kenneth Brody]

Joris Adriaenssens wrote:
[...]

I understand from other postings that casting a result from malloc
isn't good. In the past I have always been casting the malloc. I
think it was even necessary. (But that's a long time ago, I hadn't
heard of a standard for C these days). Was it really necessary or did
we do it only to silence the warnings ? (cfr. FAQ q7.7 - I can't
look in the manuals from these days : I don't have them any longer)

[...]

It was necessary back in the days when malloc() returned char* because
there was no such thing as "void" yet.

Now that malloc() returns void*, which can be implicitly converted to
anything*, it is considered "bad" to cast the return value, as this can
mask a missing header file. (ie: if malloc() isn't defined in any of
the header files, the compiler will think it returns int, and the cast
will mask the warning about converting int to a pointer.)

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer .h> |
+-------------------------+--------------------+-----------------------------+