linux-c-programming.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Memory Leak issue
@ 2002-11-16  6:59 Hemant Mohan
  2002-11-16 15:31 ` Jason P. Winters
  2002-11-16 23:53 ` Glynn Clements
  0 siblings, 2 replies; 5+ messages in thread
From: Hemant Mohan @ 2002-11-16  6:59 UTC (permalink / raw)
  To: linux-c-programming

Hi,
Is it possible to have a C function return a char*, and have void arguememnts 
without the caller having to free the memory??
I mean something like this:

char* foo(void)
{
   char *ret;
   .....
   .....  
  
   return(ret);
}

int main()
{
   ....
   char * temp;
   temp = foo();
   /* here I don't want to do a free(temp) */
   .....

}

To my understanding in this case the function foo will have to internally to 
do a malloc for ret before doing any processing on it. And it will not be 
able free this memory.  This implies that the calling function will have to 
free the return pointer of foo somewhere to prevent any memory leakeage.  Is 
there any alternative solution to return a char* ?

Thanks,
Hemant Mohan

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Memory Leak issue
  2002-11-16  6:59 Memory Leak issue Hemant Mohan
@ 2002-11-16 15:31 ` Jason P. Winters
  2002-11-16 23:53 ` Glynn Clements
  1 sibling, 0 replies; 5+ messages in thread
From: Jason P. Winters @ 2002-11-16 15:31 UTC (permalink / raw)
  To: hemantm; +Cc: linux-c-programming

 
> Is it possible to have a C function return a char*, and have void arguememnts 
> without the caller having to free the memory??
> I mean something like this:
> 
> char* foo(void)
> {
>    char *ret;
>    .....  
>   
>    return(ret);
> }
> 
> int main()
> {
>    ....
>    char * temp;
>    temp = foo();
>    /* here I don't want to do a free(temp) */
>    .....
> 
> }


> To my understanding in this case the function foo will have to internally to 
> do a malloc for ret before doing any processing on it.

This is very true.

> And it will not be able free this memory.  This implies that the calling
> function will have to free the return pointer of foo somewhere to prevent
> any memory leakeage.  Is there any alternative solution to return a char* ?

Well, you have to get memory from somewhere... as an alternative, you could
allocate it in the main routine and pass the address along to foo instead
of void, but you still end up with main having to free memory.

Basically, if you get it, you have to free it...  at some point or another.

Why are you trying to avoid freeing memory?

Ciao!

Jason
-- 
|UUCP  jason@txt.com                        Who wills, Can.
|VOICE (408) 243-3425                         Who tries, Does.
|LOCAL Hey, Jason!                              Who loves, Lives.          o_.
|Disclaimer:  Not me! I didn't do *THAT!*                                 <|
|Local Disclaimer:  I'm not here!                   A. McCaffrey           4

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Memory Leak issue
  2002-11-16  6:59 Memory Leak issue Hemant Mohan
  2002-11-16 15:31 ` Jason P. Winters
@ 2002-11-16 23:53 ` Glynn Clements
  2002-11-18  5:57   ` Hemant Mohan
  1 sibling, 1 reply; 5+ messages in thread
From: Glynn Clements @ 2002-11-16 23:53 UTC (permalink / raw)
  To: hemantm; +Cc: linux-c-programming


Hemant Mohan wrote:

> Is it possible to have a C function return a char*, and have void arguememnts 
> without the caller having to free the memory??
> I mean something like this:
> 
> char* foo(void)
> {
>    char *ret;
>    .....
>    .....  
>   
>    return(ret);
> }
> 
> int main()
> {
>    ....
>    char * temp;
>    temp = foo();
>    /* here I don't want to do a free(temp) */
>    .....
> 
> }
> 
> To my understanding in this case the function foo will have to internally to 
> do a malloc for ret before doing any processing on it. And it will not be 
> able free this memory.  This implies that the calling function will have to 
> free the return pointer of foo somewhere to prevent any memory leakeage.  Is 
> there any alternative solution to return a char* ?

If you can be sure that you only need to use last result from foo(),
you can return a pointer to statically allocated memory, e.g.

	char *foo(void)
	{
		static char buff[...];
		...
		return buff;
	}

Or you can dynamically allocate the memory but store it in a static
pointer, e.g.

	char *foo(void)
	{
		static char *ptr;
		if (ptr)
			free(ptr);
		ptr = malloc(...);
		...
		return ptr;
	}

These won't leak memory, but you have to ensure that you have finished
using the result from the previous call to foo() before calling it
again. That rules out using this approach in multi-threaded programs.

A few library functions work this way, e.g. gethostbyname(),
gethostent(), getmntent(), getpwent() etc. However, it requires the
caller to either use the return value before control is passed to
anything which might need to call the function again, or to copy the
data.

If you need the data to remain valid indefinitely, then the simplest
approach is to have foo() allocate the data with malloc() and make the
caller responsible for free()ing it when it's no longer needed.

However, if you need to do this a lot, and keeping track of the memory
is likely to be a lot of work, then it may be worth considering a
garbage-collecting allocator. This is the mechanism which is used by
most high-level languages. Here, data is dynamically allocated, and is
freed automatically when it's no longer used.

The tricky part is in determining when data is no longer used. The
need for the garbage collector to make this decision normally imposes
certain rules upon the overall program. Consequently, garbage
collection is normally only used where the effort involved in
"manually" tracking dynamically-allocated memory would be so high that
a garbage-collecting allocator is the only feasible solution.

-- 
Glynn Clements <glynn.clements@virgin.net>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Memory Leak issue
  2002-11-16 23:53 ` Glynn Clements
@ 2002-11-18  5:57   ` Hemant Mohan
  2002-11-18  7:10     ` Dimitar Peikov
  0 siblings, 1 reply; 5+ messages in thread
From: Hemant Mohan @ 2002-11-18  5:57 UTC (permalink / raw)
  To: Glynn Clements; +Cc: linux-c-programming

As I am working in a multi threaded environment, I think the garbage 
collector approach may be the best one.  
Can I use a time based approach for the garbage collector, I free the memory 
if that memory is not used for a certain period of time.
Also can you suggest some URLS which can help me in designing the garbage 
collector.

Thanks,
Hemant



On Sunday 17 November 2002 05:23, Glynn Clements wrote:
> Hemant Mohan wrote:
> > Is it possible to have a C function return a char*, and have void
>
> arguememnts
>
> > without the caller having to free the memory??
> > I mean something like this:
> >
> > char* foo(void)
> > {
> >    char *ret;
> >    .....
> >    .....
> >
> >    return(ret);
> > }
> >
> > int main()
> > {
> >    ....
> >    char * temp;
> >    temp = foo();
> >    /* here I don't want to do a free(temp) */
> >    .....
> >
> > }
> >
> > To my understanding in this case the function foo will have to internally
>
> to
>
> > do a malloc for ret before doing any processing on it. And it will not be
> > able free this memory.  This implies that the calling function will have
>
> to
>
> > free the return pointer of foo somewhere to prevent any memory leakeage.
>
> Is
>
> > there any alternative solution to return a char* ?
>
> If you can be sure that you only need to use last result from foo(),
> you can return a pointer to statically allocated memory, e.g.
>
>      char *foo(void)
>      {
>           static char buff[...];
>           ...
>           return buff;
>      }
>
> Or you can dynamically allocate the memory but store it in a static
> pointer, e.g.
>
>      char *foo(void)
>      {
>           static char *ptr;
>           if (ptr)
>                free(ptr);
>           ptr = malloc(...);
>           ...
>           return ptr;
>      }
>
> These won't leak memory, but you have to ensure that you have finished
> using the result from the previous call to foo() before calling it
> again. That rules out using this approach in multi-threaded programs.
>
> A few library functions work this way, e.g. gethostbyname(),
> gethostent(), getmntent(), getpwent() etc. However, it requires the
> caller to either use the return value before control is passed to
> anything which might need to call the function again, or to copy the
> data.
>
> If you need the data to remain valid indefinitely, then the simplest
> approach is to have foo() allocate the data with malloc() and make the
> caller responsible for free()ing it when it's no longer needed.
>
> However, if you need to do this a lot, and keeping track of the memory
> is likely to be a lot of work, then it may be worth considering a
> garbage-collecting allocator. This is the mechanism which is used by
> most high-level languages. Here, data is dynamically allocated, and is
> freed automatically when it's no longer used.
>
> The tricky part is in determining when data is no longer used. The
> need for the garbage collector to make this decision normally imposes
> certain rules upon the overall program. Consequently, garbage
> collection is normally only used where the effort involved in
> "manually" tracking dynamically-allocated memory would be so high that
> a garbage-collecting allocator is the only feasible solution.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Memory Leak issue
  2002-11-18  5:57   ` Hemant Mohan
@ 2002-11-18  7:10     ` Dimitar Peikov
  0 siblings, 0 replies; 5+ messages in thread
From: Dimitar Peikov @ 2002-11-18  7:10 UTC (permalink / raw)
  To: linux-c-programming

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

On Monday 18 November 2002 07:57, Hemant Mohan wrote:
> As I am working in a multi threaded environment, I think the garbage
> collector approach may be the best one.
> Can I use a time based approach for the garbage collector, I free the
> memory if that memory is not used for a certain period of time.
> Also can you suggest some URLS which can help me in designing the garbage
> collector.

If your threads are time dependent ... some kind of external synchronization 
not in the scope of the threads, who has to guarantee that this memory is 
free? Instead see the Java or .NET garbage collectors design patterns.

>
> Thanks,
> Hemant
>
> On Sunday 17 November 2002 05:23, Glynn Clements wrote:
> > Hemant Mohan wrote:
> > > Is it possible to have a C function return a char*, and have void
> >
> > arguememnts
> >
> > > without the caller having to free the memory??
> > > I mean something like this:
> > >
> > > char* foo(void)
> > > {
> > >    char *ret;
> > >    .....
> > >    .....
> > >
> > >    return(ret);
> > > }
> > >
> > > int main()
> > > {
> > >    ....
> > >    char * temp;
> > >    temp = foo();
> > >    /* here I don't want to do a free(temp) */
> > >    .....
> > >
> > > }
> > >
> > > To my understanding in this case the function foo will have to
> > > internally
> >
> > to
> >
> > > do a malloc for ret before doing any processing on it. And it will not
> > > be able free this memory.  This implies that the calling function will
> > > have
> >
> > to
> >
> > > free the return pointer of foo somewhere to prevent any memory
> > > leakeage.
> >
> > Is
> >
> > > there any alternative solution to return a char* ?
> >
> > If you can be sure that you only need to use last result from foo(),
> > you can return a pointer to statically allocated memory, e.g.
> >
> >      char *foo(void)
> >      {
> >           static char buff[...];
> >           ...
> >           return buff;
> >      }
> >
> > Or you can dynamically allocate the memory but store it in a static
> > pointer, e.g.
> >
> >      char *foo(void)
> >      {
> >           static char *ptr;
> >           if (ptr)
> >                free(ptr);
> >           ptr = malloc(...);
> >           ...
> >           return ptr;
> >      }
> >
> > These won't leak memory, but you have to ensure that you have finished
> > using the result from the previous call to foo() before calling it
> > again. That rules out using this approach in multi-threaded programs.
> >
> > A few library functions work this way, e.g. gethostbyname(),
> > gethostent(), getmntent(), getpwent() etc. However, it requires the
> > caller to either use the return value before control is passed to
> > anything which might need to call the function again, or to copy the
> > data.
> >
> > If you need the data to remain valid indefinitely, then the simplest
> > approach is to have foo() allocate the data with malloc() and make the
> > caller responsible for free()ing it when it's no longer needed.
> >
> > However, if you need to do this a lot, and keeping track of the memory
> > is likely to be a lot of work, then it may be worth considering a
> > garbage-collecting allocator. This is the mechanism which is used by
> > most high-level languages. Here, data is dynamically allocated, and is
> > freed automatically when it's no longer used.
> >
> > The tricky part is in determining when data is no longer used. The
> > need for the garbage collector to make this decision normally imposes
> > certain rules upon the overall program. Consequently, garbage
> > collection is normally only used where the effort involved in
> > "manually" tracking dynamically-allocated memory would be so high that
> > a garbage-collecting allocator is the only feasible solution.
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-c-programming" in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

- -- 
Dimitar Peikov
Programmer Analyst
Globalization Group
"We Build e-Business"  

RILA Solutions  
27 Building, Acad.G.Bonchev Str.  
1113 Sofia, Bulgaria  

phone: (+359 2) 9797320 
phone: (+359 2) 9797300 
fax:   (+359 2) 9733355  
http://www.rila.com 

GnuPG key       http://earth.rila.bg/~mitko/mitko.key.asc
GnuPG key       http://www.bgzone.com/~mitko/mitko.key.asc
Key fingerprint 97AF 6192 78E2 AC68 FD56  CCB0 68B9 DF7D B3C1 9ED7
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE92JJTaLnffbPBntcRAouTAJ96UpcW27B7QVy6/PfT8HWPMo5eggCgl2r4
86ymnUlfZQmmL/twfMyzQtk=
=9W7L
-----END PGP SIGNATURE-----

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2002-11-18  7:10 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-11-16  6:59 Memory Leak issue Hemant Mohan
2002-11-16 15:31 ` Jason P. Winters
2002-11-16 23:53 ` Glynn Clements
2002-11-18  5:57   ` Hemant Mohan
2002-11-18  7:10     ` Dimitar Peikov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).