where is the end of free()?

[Thomas Zhu]

would someone tell me:


s1: int *ptr = (int *) malloc (sizeof(int));

s2: int *ptr = (int *) malloc (n * sizeof(int));

when i use free(ptr),

what is the difference between the two statements?


thanks in advance.

 

[Madhav]

would someone tell me:


s1: int *ptr = (int *) malloc (sizeof(int));

s2: int *ptr = (int *) malloc (n * sizeof(int));

Please remove the cast. you don't need to cast the value returned by
malloc. Please include stdlib.h.

The difference in the above two statements is the number of bytes
which are marked as reusable.

 

[Thomas Zhu]

thanks.

but :

ptr = (int *) malloc (n * sizeof(int));
ptr ++;

free(ptr);

does the system free n mem-units or n-1 mem-units?

and why the cast is not necessary?

 

[Marc Boyer]

ptr = (int *) malloc (n * sizeof(int));
ptr ++;

free(ptr);

does the system free n mem-units or n-1 mem-units?

Neither one nor the other. This is UB.

and why the cast is not necessary?

Because malloc returns a void* pointer, and it
can be implicitely converted into int*.

Marc Boyer

 

[Villy Kruse]

Neither one nor the other. This is UB.

In this case very likely a painfull UB.

In many implementations the size of an allocated buffer is stored
somwhere just before the buffer itself, and free finds that using a
negative offset from the passed pointer. Obviously, if the ptr given
to free doesn't have the same value as returned from a call to malloc,
free can't find the size of the buffer and thus can't free it properly.

Villy

 

[Christopher Benson-Manica]

ptr = (int *) malloc (n * sizeof(int));
ptr ++;

does the system free n mem-units or n-1 mem-units?

Neither. If you pass a pointer to free() that was not returned by a
call to malloc(), you get "undefined behavior" - in other words,
absolutely anything may happen at that point.

Furthermore, all you need to know about free() is that it deallocates
all the memory reserved by malloc(); that amount is at least, but by
no means limited to, the amount of memory you asked for.

 

[Thomas Zhu]

I''ve got it!!!

I often heard some words (I dont know the their English name , i
translate them from my language to English):
1/memory leak
2/wild pointer

is there any good online books on them ?

thanks a lot.

 

[Emmanuel Delahaye]

Thomas Zhu a écrit :

ptr = (int *) malloc (n * sizeof(int));

What are the words you don't understand in:

"Please remove the cast. you don't need to cast the value returned by
malloc. Please include stdlib.h."

ptr ++;

free(ptr);

Undefined behaviour.

The value passed to free() must exactly be the value received from malloc().

 

[Thomas Zhu]

Thanks a lot.

I've got it.
I supposed that the compiler would give a warning to the statement
without a cast.
But I was wrong.
Just now I tried some compilers, they all works.

 

[Emmanuel Delahaye]

Thomas Zhu a écrit :

I often heard some words (I dont know the their English name , i
translate them from my language to English):
1/memory leak

Meaning that some allocated memory can't be freed(). It may happen if
you loose the value of the pointer.

printf ("%p\n", (void *) malloc(123));

or more likely (Ok, strdup() not standard C but is POSIX.1, hence very
portable)

printf ("%s\n", strdup("Hello world"));

2/wild pointer

or 'dandling pointer'. An uninitialized pointer or a pointer to an
invalid zone (out of the limits of an array for example). As long as you
don't dereference it, it's fine (well, sort of). But if you dereference
it, it bites (UB).

 

[Pierre Maurette]

Thomas Zhu, le 21/10/2005, a écrit :

Thanks a lot.

I've got it.
I supposed that the compiler would give a warning to the statement
without a cast.
But I was wrong.

C++ give an error whithout the cast.
IMHO, it is not a mortal sin to cast the malloc() return in both C and
C++.

 

[Emmanuel Delahaye]

Pierre Maurette a écrit :

C++ give an error whithout the cast.

Who cares... What is C++ ?

IMHO, it is not a mortal sin to cast the malloc() return in both C and C++.

.... but is can hide some nasty bug, like to forget to include <stdlib.h>

 

[Emmanuel Delahaye]

Pierre Maurette a écrit :

C++ give an error whithout the cast.

Who cares... What is C++ ?

IMHO, it is not a mortal sin to cast the malloc() return in both C and C++.

.... but it can hide some nasty bug, like to forget to include <stdlib.h>

 

[TomHanks]

and why the cast is not necessary?

Why is not needed, the cast is needed as pointer from void* to non-void
requires an explicit cast.

 

[Christopher Benson-Manica]

Why is not needed, the cast is needed as pointer from void* to non-void
requires an explicit cast.

Wrong.

 

[Default User]

Thomas Zhu, le 21/10/2005, a écrit :

C++ give an error whithout the cast.

So? This is not C++;

IMHO, it is not a mortal sin to cast the malloc() return in both C
and C++.

You shouldn't be using malloc() in C++. You should be using new.
Writing code to be cross-language compatible is usually a waste of time
and inefficient, outside of a few library developers.


Brian

 

[Default User]

Thanks a lot.

I've got it.
I supposed that the compiler would give a warning to the statement
without a cast.
But I was wrong.
Just now I tried some compilers, they all works.

Please read my .sig.


Brian

 

[Pierre Maurette]

Default User, le 21/10/2005, a écrit :

So? This is not C++;

My english is so bad. I prefer to b concise. And you seem to need
verbose mode:
Maybe

You shouldn't be using malloc() in C++. You should be using new.
Writing code to be cross-language compatible is usually a waste of time
and inefficient, outside of a few library developers.

Yes. It is not a good idea, unless whn it is.

 

[Default User]

Default User, le 21/10/2005, a écrit :
My english is so bad. I prefer to b concise.

Your English would improve automatically by not using strange
abreviations.

And you seem to need verbose mode: Maybe

"Maybe"? Maybe what? I certainly could use more verbosity here, as I
have no idea what you mean.

Yes. It is not a good idea, unless whn it is.

Well, that certainly covers it.


Brian

 

[Razzer]

Neither. If you pass a pointer to free() that was not returned by a
call to malloc(), you get "undefined behavior" - in other words,
absolutely anything may happen at that point.

Which techincally means that the implementation could free "n mem-units
or n-1 mem units". Not that you should rely on this behavior, but I
just want to point out on the broad abilities of a computer to do
mischief .