| Author |
Message |
|
Lase
#1 / 14
|
 a question about malloc and free consider following codes
int abc()
{
......
/*p is a local variable*/
p=(char*)malloc(n*sizeof(char));
......
Quote: }
within this function if i didn't use free(p), what will happen to such
space had been allocated? p is a local variable and will vanish
outside this function, could space allocated get free along with the
pointer, or keep till the program exit?
|
| Wed, 26 May 2004 00:09:09 GMT |
|
 |
|
Morris Dove
#2 / 14
|
a question about malloc and free Quote:
> consider following codes
> int abc()
> {
> ......
> /*p is a local variable*/
> p=(char*)malloc(n*sizeof(char));
> ......
> }
> within this function if i didn't use free(p), what will happen to such
> space had been allocated? p is a local variable and will vanish
> outside this function, could space allocated get free along with the
> pointer, or keep till the program exit?
Laser...
The space will remain until the program terminates. This is a
"leak".
--
Morris Dovey
West Des Moines, Iowa USA
|
| Tue, 25 May 2004 23:13:05 GMT |
|
|
|
willem veenhove
#3 / 14
|
a question about malloc and free Quote:
> consider following codes
> int abc()
> {
> ......
> /*p is a local variable*/
> p=(char*)malloc(n*sizeof(char));
p = malloc(n); /* sizeof(char) is 1 by definition! */
Quote: > ...... > } > within this function if i didn't use free(p), what will happen
> to such space had been allocated?
program's lifespan, if you're lucky ... as far as I know there
is no requirement in the C standard that the memory is returned
to the OS when your programs closes, so the memory may even get
lost until the next time you reboot your system. So you'd better
make it a habit to free all memory that you allocated.
willem
|
| Wed, 26 May 2004 00:35:16 GMT |
|
|
|
Mike Wahle
#4 / 14
|
a question about malloc and free Quote:
>consider following codes >int abc()
>{
> ......
> /*p is a local variable*/
> p=(char*)malloc(n*sizeof(char));
> ......
>}
>within this function if i didn't use free(p), what will happen
Your program now has a 'memory leak'. The allocated memory
is no longer accessible. It might or might not be returned
to your OS upon program termination, depending on your system.
*Always* free() *all* allocated memory when you're done with
it.
-Mike
|
| Wed, 26 May 2004 01:10:17 GMT |
|
|
|
Bill Godfre
#5 / 14
|
a question about malloc and free Quote:
> > int abc()
<snip>
> > p=(char*)malloc(n*sizeof(char));
<snip>
> > within this function if i didn't use free(p), what will happen to such
> The space will remain until the program terminates. This is a
> "leak".
Not necessarily. Unless I'm very much mistaken, the standard does not
forbid an implementation to "garbage collect".
However, I don't know of any garbage-collecting C implementations. So
your answer to the OP is probably correct.
(So file my article here under "theoretical flights of fancy")
Having said that, I have seen C implementations optimized for debugging,
which uses garbage collection techniques to warn of memory leak errors.
But ultimatly, most (all?) C implementations used for running "production
code" will not have garbage collection, beyond freeing all memory when
the program exits. Probably because it would be a such a bad thing.
Bill, free() your mind!
|
| Wed, 26 May 2004 01:11:54 GMT |
|
|
|
Ben Pfaf
#6 / 14
|
a question about malloc and free Quote:
> int abc()
> {
> ......
> /*p is a local variable*/
> p=(char*)malloc(n*sizeof(char));
> ......
> }
When calling malloc(), I recommend using the sizeof operator on the
object you are allocating, not on the type. For instance, *don't*
write this:
int *x = malloc (sizeof (int) * 128); /* Don't do this! */
Instead, write it this way:
int *x = malloc (sizeof *x * 128);
There's a few reasons to do it this way:
* If you ever change the type that `x' points to, it's not
necessary to change the malloc() call as well.
This is more of a problem in a large program, but it's still
convenient in a small one.
* Taking the size of an object makes your sizeof call more
similar to your declaration, which makes writing the
statement less error-prone.
For instance, above, the declaration syntax is `*x' and the
sizeof operation is also written `*x'. This provides a
visual clue that the malloc() call is correct.
I don't recommend casting the return value of malloc():
* The cast is not required in ANSI C.
* Casting its return value can mask a failure to #include
<stdlib.h>, which leads to undefined behavior.
* If you cast to the wrong type by accident, odd failures can
result.
Also, sizeof(char) is always 1.
Quote: > within this function if i didn't use free(p), what will happen to such
> space had been allocated?
It would probably not be freed until the end of your program.
--
"IMO, Perl is an excellent language to break your teeth on"
--Micah Cowan
|
| Wed, 26 May 2004 01:54:22 GMT |
|
|
|
Micah Cowa
#7 / 14
|
a question about malloc and free Quote:
> consider following codes > int abc()
> {
> ......
> /*p is a local variable*/
> p=(char*)malloc(n*sizeof(char));
> ......
> }
> within this function if i didn't use free(p), what will happen to such
> space had been allocated? p is a local variable and will vanish
> outside this function, could space allocated get free along with the
> pointer, or keep till the program exit?
It'll keep till (and perhaps beyond) the program exit. This is a
memory leak. If you don't explicitly free() all pointers that you
malloc(), in one way or another, you have a memory leak.
Micah
--
For what value of "work"? The program is NOT outside my home
or workplace carrying a sign featuring the word "UNFAIR" and
my name? - Gordon Burditt, resp. to "how come it seems to work?"
|
| Wed, 26 May 2004 04:09:45 GMT |
|
|
|
CBFalcone
#8 / 14
|
a question about malloc and free Quote:
> > > int abc()
> <snip>
> > > p=(char*)malloc(n*sizeof(char));
> <snip>
> > > within this function if i didn't use free(p), what will happen to such
> > The space will remain until the program terminates. This is a
> > "leak".
> Not necessarily. Unless I'm very much mistaken, the standard does not
> forbid an implementation to "garbage collect".
> However, I don't know of any garbage-collecting C implementations. So
> your answer to the OP is probably correct.
LCC-WIN32 does it. An extension, not standard.
--
Available for consulting/temporary embedded and systems.
(Remove "XXXX" from reply address. yahoo works unmodified)
|
| Wed, 26 May 2004 05:02:07 GMT |
|
|
|
Joe Wrigh
#9 / 14
|
a question about malloc and free Quote:
> But ultimatly, most (all?) C implementations used for running "production
> code" will not have garbage collection, beyond freeing all memory when
> the program exits. Probably because it would be a such a bad thing.
But it's not the C implementation that does that. Freeing allocated
memory of a terminating process is the OS's job.
--
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
|
| Wed, 26 May 2004 05:42:40 GMT |
|
|
|
Morris Dove
#10 / 14
|
a question about malloc and free Quote:
> > > int abc()
> <snip>
> > > p=(char*)malloc(n*sizeof(char));
> <snip>
> > > within this function if i didn't use free(p), what will happen to such
> > The space will remain until the program terminates. This is a
> > "leak".
> Not necessarily. Unless I'm very much mistaken, the standard does not
> forbid an implementation to "garbage collect".
> However, I don't know of any garbage-collecting C implementations. So
> your answer to the OP is probably correct.
Bill...
Ok. What happens "behind the scenes" or after program termination
isn't addressed by the standard (or by my response 8-).
Perhaps I should have said "Unless the implementation performs GC
at or after the function's return, the space will remain
allocated and inaccessable to the application through
termination."
But considering the question asked, that seemed like more
information than Laser might have been ready to digest...
<ot> Your comments do raise an interesting possibility: If a
function allocates memory and if nothing that function returns
(or stores through a passed pointer) depends on the value
returned by the allocation, the compiler /might/ be able to
generate a call to free the allocated memory. I don't think this
would really qualify as the GC you suggest, but could contribute
to reduction of memory leaks.
I think I'd prefer a diagnostic to the generated free call; but
it's an interesting thought. Thanks! </ot>
--
Morris Dovey
West Des Moines, Iowa USA
|
| Wed, 26 May 2004 05:26:11 GMT |
|
|
|
Ben Pfaf
#11 / 14
|
a question about malloc and free Quote:
> However, I don't know of any garbage-collecting C implementations. So
> your answer to the OP is probably correct.
Although it is not 100% compliant, the Boehm conservative garbage
collector works very well for most C programs.
Quote: > But ultimatly, most (all?) C implementations used for running "production
> code" will not have garbage collection, beyond freeing all memory when
> the program exits. Probably because it would be a such a bad thing.
New versions of GCC are garbage-collected. Note that that's the
compiler itself, not the code that the compiler produces.
--
"Some people *are* arrogant, and others read the FAQ."
--Chris Dollin
|
| Wed, 26 May 2004 06:34:53 GMT |
|
|
|
Martin Ambuh
#12 / 14
|
a question about malloc and free Quote:
> consider following codes
> int abc()
> {
> ......
> /*p is a local variable*/
> p=(char*)malloc(n*sizeof(char));
sizeof(char) == 1 by definition.
The only function of the cast is to hide a programmer error.
p = malloc(n);
[and of course check for an allocation error]
Quote: > ...... > } > within this function if i didn't use free(p), what will happen to such
> space had been allocated? p is a local variable and will vanish
> outside this function, could space allocated get free along with the
> pointer, or keep till the program exit?
a variable not of function scope. free() it when done with it.
|
| Wed, 26 May 2004 08:38:33 GMT |
|
|
|
Lawrence Kir
#13 / 14
|
a question about malloc and free
Quote:
>> > int abc()
><snip>
>> > p=(char*)malloc(n*sizeof(char));
><snip>
>> > within this function if i didn't use free(p), what will happen to such
>> The space will remain until the program terminates. This is a
>> "leak".
>Not necessarily. Unless I'm very much mistaken, the standard does not
>forbid an implementation to "garbage collect".
However the standard makes it impossible in practice for a conforming
implementation. For example a valid C program could wrote the value of
p above to a file and restore it later. It could copy it to an array of
char, shuffle the bytes and restore it later. A garbage collection system
would be unaware that a reference to the memory still exists and could
collect it. Essentially a conforming implementation cannot use garbage
collection because it can never be sure that an object isn't referenced
by a pointer-like value it can't detect.
Quote: >However, I don't know of any garbage-collecting C implementations. So
>your answer to the OP is probably correct.
There are garbage collectors around for C. However they place restrictions
on what the C code can do, notably it isn't allowed to do the sort of
things I mentioned above that can "hide" pointers. That isn't a great
problem in most cases.
--
-----------------------------------------
-----------------------------------------
|
| Wed, 26 May 2004 21:59:05 GMT |
|
|
|
Lawrence Kir
#14 / 14
|
a question about malloc and free
Quote:
>> consider following codes
>> int abc()
>> {
>> ......
>> /*p is a local variable*/
>> p=(char*)malloc(n*sizeof(char));
> p = malloc(n); /* sizeof(char) is 1 by definition! */
>> ......
>> }
>> within this function if i didn't use free(p), what will happen
>> to such space had been allocated?
>It will exist as unused and unusable space for the rest of the
>program's lifespan, if you're lucky ... as far as I know there
>is no requirement in the C standard that the memory is returned
>to the OS when your programs closes,
Just as there no requirement that memory you've freed is returned to
the OS or even static or outstanding automatic variables. This is a
case where it is up to you use a decent OS. :-)
Quote: >so the memory may even get
>lost until the next time you reboot your system.
That's a possibility whether you free it or not.
Quote: >So you'd better
>make it a habit to free all memory that you allocated.
That's not always necessary, although it isn't a bad principle. It is
certainly good if you use diagnostics that tell you if dynamic memory is
still allocated when a program terminates normally.
A good but slightly less stringent alternative is a rule that a program
must have the ability to access any allocated memory up to the point at
which it terminates. I.e. no memory leaks.
--
-----------------------------------------
-----------------------------------------
|
| Wed, 26 May 2004 21:52:10 GMT |
|
| |
