A "malloc" question

James Brister brister at decwrl.dec.com
Fri Apr 26 03:53:20 AEST 1991


G'day,

On 25 Apr 91 02:54:03 GMT, rvp at softserver.canberra.edu.au (Rey Paulo) said:

> Can anyone tell me if dynamically allocated storage for automatic variables
> remains allocated even if the variables have already disappeared after the
> invocation of the function.

You're not clear on what you mean here. Given the following two lines in a
function:

	char *str ;
	str = malloc (x) ;

are you referring to the space taken up by str? Or that space taken up by
*str? (i.e. the space returned by the malloc())? 

The space taken up by str will generally be on a stack, and will be
receovered by the function returning. The malloced space will not be
reclaimed automatically and this will give you a memory leak in your
program, unless you keep track of the space through another pointer other
than str.

> If it is, does this mean that "automatic" does not have any meaning at
> all for dynamically allocated storage?

When you say dynamcially you mean malloc'ed, right? Them this is true. The
"auto" storage class modifier isn't very useful (IMHO), because variables
inside a function are automatic by default.

> And one more, if I have an automatic variable in a function and I allocate
> storage for that variable using "malloc", are the following ways of freeing
> the storage the same?  In both cases, assume the variable is (char *str).

>    1) free (str)   -  inside the function where str is declared.

>    2) free (sstr)  -  inside another function where sstr is declared but
>                       made to point to str by a function call.

Yes

> University of Canberra        | I am not bound to please thee with my answer. 
> AUSTRALIA                     |         -Shylock, in "The Merchant of Venice" 

Nor am I! ;-)

James
--
James Brister                                           brister at decwrl.dec.com
DEC WSL., Palo Alto, CA                 {uunet,pacbell,pyramid}!decwrl!brister
"Old mathematicians never die; they just lose some of their functions."



More information about the Comp.unix.programmer mailing list