Problem with free()

[Pramoda.M.A]

code is :

code is :
path = (char*)malloc(100);
pname = (char*)malloc(100);
path = "ragHu";
strcpy(pname, path);
free(path);

whats wrong with this?

[kvprajapati]

code is :

code is :
path = (char*)malloc(100);
pname = (char*)malloc(100);
path = "ragHu";
strcpy(pname, path);
free(path);

whats wrong with this?

path = (char*)malloc(100);

statement allocates heap and assign base address to the path if allocation is success. (we assume that the allocation is succeed)

path = "ragHu";

- New heap is prepared to store "ragHu" and it base address of newly created heap is assigned.

and finally,

strcpy(pname, path);
free(path);

It's a memory leak!!!

[Aia]

Pramoda.M.A> whats wrong with this?

path = (char*)malloc(100); /* it is not recomened to cast malloc, just include stdlib.h and it'll know what to do */
/* malloc returns NULL when it can not allocate the requested memory, checking the return is a must */

pname = (char*)malloc(100);
/* same advise than for previous statement */

path = "ragHu";
/* re-assigning path to a literal string, makes the previous malloced memory to be in limbo, you don't have any way of accessing it back or freeing it */

strcpy(pname, path);
/* what happens if there's no memory in pname to hold path? */

free(path);
/* path doesn't point to any memory that needs to be freed */
/* pname needs to be freed at some point */

[kvprajapati]

Thank AIa, but I got confusion about the statement you wrote.

it is not recomened to cast malloc, just include stdlib.h and it'll know what to do ?

[fpmurphy]

The problem is with the line

path =  "ragHu";

It should be replaced with the following

strcpy(path, "ragHu");

[Aia]

adatapost> Thank AIa, but I got confusion about the statement you wrote.
Explanations of ... >casting malloc

[kvprajapati]

adatapost> Thank AIa, but I got confusion about the statement you wrote.
Explanations of ... >casting malloc

adatapost> Link Explanations of ... >casting malloc has inappropriate explanation of malloc function.

originally, the prototype of malloc function is :

void *malloc(size_t size);

[Aia]

adatapost> Link Explanations of ... >casting malloc has inappropriate explanation of malloc function.

originally, the prototype of malloc function is :

void *malloc(size_t size);

You are in error. There was not such a thing as a void type at the inception of the C language. Read the explanation piece again, if you must.

[kvprajapati]

Buddy Aia,

I have strong reason to say the return type of malloc is void. Following two line from MSDN are :

A pointer to void can be converted to or from a pointer to any type, without restriction or loss of information. If the result is converted back to the original type, the original pointer is recovered.

[Salem]

> I have strong reason to say the return type of malloc is void. Following two line from MSDN are :
The key word being "is".
Which isn't the same as "was" or "always has been".

[kvprajapati]

Hi Salem.

I didn't got you. What do you say about the malloc() function.

[Aia]

Buddy Aia,
I have strong reason to say the return type of malloc is void.

Let me try to make you understand.
The practice of casting malloc comes from way before there was a type void in the language C. char * was used as kind of generic pointer to fill the need.
Today we enjoy the void type, and malloc makes use of it. To cast malloc is by-passing the prescribed prototype defined in the stdlib.h header file; and if you do, it is at your own peril.

[Salem]

The current practice of casting malloc stems from people trying to write C code using a C++ compiler.

C++ does NOT allow void* to T* conversions without a cast (which is exactly what a malloc result assignment is).
Otherwise known as bashing the slightly round peg into the slightly square hole.

The solution is to commit to using either C or C++ (figure out how to compile it as C, or use 'new' in place of malloc).

To do otherwise is to have a mish-mash of random syntax called c/c++ which just about does what you want, so long as you don't do anything more complicated than the usual student assignment.

Occasionally unavoidable if you're maintaining something with history. But students writing new code should really be making better use of the tools.