[161] in Hesiod
Re: Major memory leak in hes_resolv
daemon@ATHENA.MIT.EDU (Jeff Kutcher)
Mon Oct 11 08:48:19 1993
Date: Mon, 11 Oct 93 07:42 CDT
From: kutcher@nisus.eng.hou.compaq.com (Jeff Kutcher)
To: tytso@MIT.EDU
Cc: hesiod@MIT.EDU, kutcher@nisus.MIT.EDU, mcb@mach.eng.hou.compaq.com
> It is the program's responsibility to free the data structures returned
> by hes_resolve. In this fashion, hes_resolve is more like strdup() in
> that it returns a pointer to allocated memory, than gethostbyname()
> which returns a pointer static memory.
>
> So it's not a bug, but an issue of misunderstanding the programming
> interface to hes_resolve().
>
> It's actually a feature, since if a program nees to call hes_resolve
> multiple times to get various different pieces of information, it
> doesn't need to copy the returned information to a another variable
> before calling hes_resolve() again. Contrast this with the behavior of
> gethostbyname(), where many a bug has been called by having a procedure
> call gethostbyname(), and having it try to use the resulting information
> both before and after calling another function which also happens to
> call gethostbyname() for another purpose, unbeknownst to the author of
> the first procedure....
>
> - Ted
There would still be a memory leak. Multiple calls to gethostbyname() by
various functions would result in multiple allocated chunks/blocks of
memory. Unless the programmer knows to free the *contents* of the hostent
structure, the memory leak will persist and programs will slowly eat away
at the system memory. This, too, isn't documented. And besides, I've yet
to see one program that calls gethostbyname() and later frees
hostent->h_name. In fact, we are lucky that the first field in the
hostent structure is defined as a character pointer. If it were defined
as say an integer, how would one free the block at that point?
Jeff
