malloc and free?

[rockdale]

char* temp = (char*) malloc(10*sizeof(char));
temp="0123456789";
free(temp);

the free(temp) line got the error:
File: f:\\dd\vctools\crt_bld\self_x86\crt\src\dbgheap.c
Line: 1317
Expression: _CrtIsValidHeapPointer(pUserData)

if I change the assignment of temp as following
temp[0] = 'a';
temp[1] = 'a';
temp[2] = 'a';
temp[3] = 'a';
temp[4] = 'a';
temp[5] = 'a';
temp[6] = '\0';

anybody can explain this to me.

I am using Visual Studio 2008 on windows xp.

Is that a Visual Studio problem or it is my code?

thanks in advance.

 

[MisterE]

char* temp = (char*) malloc(10*sizeof(char));

You assign temp to point to 10 chars of allocated memory

temp="0123456789";

Here you are re-assigning temp to something different: to point to a fixed
string of 11 bytes.
You have now lost track of the 10 bytes you allocated.

free(temp);

Here you are trying to free something you didn't allocate.


What you need to do is this:

char *temp = malloc(11*sizeof(char));
strcpy(temp,"0123456789");
free(temp);

 

[rockdale]

Thank you. That explains.

You assign temp to point to 10 chars of allocated memory


Here you are re-assigning temp to something different: to point to a fixed
string of 11 bytes.
You have now lost track of the 10 bytes you allocated.


Here you are trying to free something you didn't allocate.

What you need to do is this:

char *temp = malloc(11*sizeof(char));
strcpy(temp,"0123456789");
free(temp);

 

[Martin Ambuhl]

char* temp = (char*) malloc(10*sizeof(char));

The cast is useless and poor style. If your compiler thinks you need
it, then you are either compiling a language other than C or you have
forgotten to include <stdlib.h>

sizeof(char) is 1 by definition, so '*sizeof(char)' is just typing practice.

temp="0123456789";

Killing the value you just stored in temp and making the space you
allocated with nothing pointing to it.

temp now points to the string literal "0123456789". If you want to copy
that into your array use strcpy, but that literal has 11 chars, the last
one being '\0', and an attempt to copy will involve an illegal memory
access unless you allocate 11 bytes instead of 10.

free(temp);

But temp points to a string literal, which you can't legally free. And
the space you allocated with malloc is still there, but inaccessible and
is a memory leak.

 

[Ian Collins]

You assign temp to point to 10 chars of allocated memory


Here you are re-assigning temp to something different: to point to a fixed
string of 11 bytes.
You have now lost track of the 10 bytes you allocated.


Here you are trying to free something you didn't allocate.


What you need to do is this:

char *temp = malloc(11*sizeof(char));

Not forgetting sizeof(char) is 1.

char *temp = malloc(11);

 

[Richard Bos]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

rockdale <[email protected]>


OK, like any malloc(3)

Very unlike any malloc(3), but very like malloc(10).

Wrong. You can't simply override the malloc(3) given value
and let the pointer without the right reference. Instead of
assignment, try using a memory copying function like memcpy(3)
or memmove(3).

Both memcpy() and memmove() need three arguments, and only the last one
can be an uncast integer. In any case, strcpy() would be a much better
choice.

You can't get free(3) working with the wrong pointer.

He isn't free()ing 3, he's free()ing temp. And that's the right pointer
object, but at that point it no longer holds the right value.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (FreeBSD)

Are you really so insecure about your own identity that you need all
this broken signature crap?

Richard

 

[jameskuyper]

Very unlike any malloc(3), but very like malloc(10).

I didn't realize it at the time, but I just figured out that he might
be using malloc(3) to identify the fact that, on typical unix-like
machines, malloc is documented in section 3 of the online manual.

Similarly for free(3):

 

[Bill Cunningham]

Very unlike any malloc(3), but very like malloc(10).


Both memcpy() and memmove() need three arguments, and only the last one
can be an uncast integer. In any case, strcpy() would be a much better
choice.


He isn't free()ing 3, he's free()ing temp. And that's the right pointer
object, but at that point it no longer holds the right value.

[snip]

Interesting. Thanks for the info. I will remember this.

Bill

 

[Phil Carmody]

Very unlike any malloc(3), but very like malloc(10).

Doofus. That's a reference to the section the man page for
malloc can be found in.

Both memcpy() and memmove() need three arguments, and only the last one
can be an uncast integer. In any case, strcpy() would be a much better
choice.

Why didn't you mention the (3) in that paragraph?

He isn't free()ing 3, he's free()ing temp. And that's the right pointer
object, but at that point it no longer holds the right value.

You're being a doofus again there.

Phil

 

[James Kuyper]

Doofus. That's a reference to the section the man page for
malloc can be found in.

Not everyone is familiar with 'man'. I am very familiar with it, and I
still didn't recognize the reference when I first read that message; I
don't think it's reasonable to expect that notation to be understood by
a general audience in this context.

 

[Richard Bos]

Doofus. That's a reference to the section the man page for
malloc can be found in.

> FIND MAN PAGE

I see no "MAN PAGE" here.

IOW, what is an obvious reference to you might be so much gobbledygook
to someone using another system. And malloc(3) _is_ a valid function
call, unlike most such All-The-World's-A-Unixisms, so it's doubly unwise
to use it.

Why didn't you mention the (3) in that paragraph?

Doofus. I did. First sentence.

Richard

 

[Default User]

I see no "MAN PAGE" here.

Oh man, if only this were IF. A cloud of sinister black smoke to take
the trolls away.




Brian

 

[John Bode]

Doofus. That's a reference to the section the man page for
malloc can be found in.

Dude. Chill. A little humor never hurt anybody.

 

[Phil Carmody]

Doofus. I did. First sentence.

The first sentence is "Both memcpy() and memmove() need three arguments,
and only the last one can be an uncast integer.". Do you have alternative
definitions of "Doofus", "I", "did", "first", or "sentence" to the rest
of the world?

Phil

 

[Harald van Dijk]

The first sentence is "Both memcpy() and memmove() need three arguments,
and only the last one can be an uncast integer.". Do you have
alternative definitions of "Doofus", "I", "did", "first", or "sentence"
to the rest of the world?

Richard pointed out that the number and types of parameters of memcpy and
memmove do not correspond to the number and type of the one argument in
memcpy(3) and memmove(3).

 

[Stephen Sprunk]

Richard pointed out that the number and types of parameters of memcpy and
memmove do not correspond to the number and type of the one argument in
memcpy(3) and memmove(3).

Unix programmers often put the man page section of a function in
parentheses after the name, i.e. memcpy(3) refers to the memcpy() in
section 3 (the Standard C Library) of the Unix manual. This convention
evolved because some functions are listed in multiple sections (with
differing explanations), or the same name may be used in another section
for a non-function purpose.

I agree that it is confusing and shouldn't be done on c.l.c, so flame
the writer for it if you must, but deliberately misreading it doesn't
help anyone.

S

 

[Kaz Kylheku]

Unix programmers often put the man page section of a function in
parentheses after the name, i.e. memcpy(3) refers to the memcpy() in
section 3 (the Standard C Library) of the Unix manual.

Unix programmers who do this in a platform-independent discussion forum are
either idiots who don't realize that there are platforms programmed using C
that aren't Unix, or else they use the notation out of platform chauvinism.
I.e. since C came from Unix, every C programmer should ``come home'' to ``where
it all came from'' and read the holy scriptures of the man command.

Hence, the flippant responses you get, like ``sorry malloc(3) passes
the wrong number and types of arguments''. People know well what you mean,
but are trolling you back.

In this newsgroup you're supposed to know that the definition of malloc is in
standard C. It has not been defined by man pages for more than thirty years
now.

 

[Phil Carmody]

Richard pointed out that the number and types of parameters of memcpy and
memmove do not correspond to the number and type of the one argument in
memcpy(3) and memmove(3).

Keep up, please. You're pulling a Chuck currently.

Phil

 

[Harald van Dijk]

Keep up, please. You're pulling a Chuck currently.

If you think I was wrong in my interpretation of Richard's or your
messages, I'd appreciate it if you would point out why. It seems to me
that Richard was making a point about (3), and you didn't get it. If you
did get it, you didn't make that clear in your messages.

 

[Phil Carmody]

If you think I was wrong in my interpretation of Richard's or your
messages, I'd appreciate it if you would point out why. It seems to me
that Richard was making a point about (3), and you didn't get it. If you
did get it, you didn't make that clear in your messages.

I do think your wrong, that should have been clear. However, IMHO,
everything necessary has already been said, if you can't work it
out then my Chuck comment is doubly accurate. Perhaps I can break
it down into simple yes/no questions (with clues as to the expected
answers).

1) Do you think that in the paragraph indented with ">>>>>> >" at
the top of this post mentions the "(3)"?
(Answer - No.)

2) Does my response to that paragraph inquire why the "(3)" was
not mentioned in that specific paragraph?
(Answer - Yes.)

3) Does the answer to that question claim that such a mention
is in the first sentence of the paragraph in question?
(Answer - Yes.)

4) Is there such a mention in the paragraph in question?
(Answer - should be obvious given the answer to question 1)

5) Is Richard a doofus?
(Answer - Yes.)

Phil