From owner-freebsd-hackers Fri Sep 12 16:42:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA18755 for hackers-outgoing; Fri, 12 Sep 1997 16:42:29 -0700 (PDT) Received: from kf0yn.ampr.org ([204.176.110.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA18750 for ; Fri, 12 Sep 1997 16:42:26 -0700 (PDT) Received: from [44.50.32.7] (kf0yn-mb.ampr.org [44.50.32.7]) by kf0yn.ampr.org (8.8.5/8.6.5) with ESMTP id SAA20671; Fri, 12 Sep 1997 18:40:44 -0500 (CDT) X-Sender: cmf@44.50.32.6 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Sep 1997 18:40:53 -0500 To: Terry Lambert From: Carl Fongheiser Subject: Re: Memory leak in getservbyXXX? Cc: freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >To the user: you should note that the threaded libc differs from the >standard libc in that, instead of returning pointers to function >modified static data areas, most functions which formerly did just >that now return allocated buffers which contain the results, and it >is now the user's responsibility to free these buffers. > >The use of static data buffers in libc is a long-standing abomination, >blessed by ANSI and codified in stone by POSIX. Assume any man page >which states a pointer to a static data area is returned is actually >allocating a data area and expecting the caller to free it, whenever >you are using a thread-safe library. It may be an abomination, but it's also a fact of life. The pthread interface *does* provide a way to cope -- check out pthread_key_create(), pthread_setspecific() and pthread_getspecific(). You even get to specify a destructor routine, so you can automagically clean up your allocated buffers inside the library! Carl Fongheiser cmf@netins.net