Re: NEVER USE return str_dup(s);

From: Katzlberger Thomas (cat@garfield.Vanderbilt.Edu)
Date: 09/15/95


Hi all !

Scatter <scatter@Onramp.NET> wrote:
> How on earth does returning a strdup create a memory leak?
> If value is freed when your done with it, there is no leak.
  ^^^^^^^^^^^^^^^^^
> This call seems to be just an enhanced malloc....

1.) Are you sure that every other imp on your MUD will know that
he has to free the return value of your function explicitly ?
A function returning char* is nothing special but a function
returning a malloced copy of a char* is something special.
-> tell me 3 other functions of UNIX returning a malloced
   char* ...

2.) If you have ever done a malloc-debug you know that avoiding
possible memory leaks is easier than finding them.

3.) Suppose your function gets into a library archive like lib_mud.a
Are you sure everybody will expect to free the return value ?

4.) This type of function has its place like in:
	file_to_string_alloc
	db_read_malloc_string
The unique characterization is that they WARN you in the function name.

5.) A LOCAL BUFFER NEVER uses return str_dup(s);
   What was what we were talking about.

If you think none of these points is valid do it.

Cat.
PS: hope I didn't flame too much ;).
--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/_/                                                            _/_/
_/_/  Thomas Katzlberger                                        _/_/
_/_/  katzlbt@vuse.vanderbilt.edu                               _/_/
_/_/  @aBlackNeXT.called.garfield                               _/_/
_/_/  http://www.vuse.vanderbilt.edu/~katzlbt/                  _/_/
_/_/                                                            _/_/
_/_/  "You can tune a file system, but you can't tune a fish."  _/_/
_/_/                                UNIX man page for tunefs.   _/_/
_/_/                                                            _/_/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/



This archive was generated by hypermail 2b30 : 12/07/00 PST