Date: Tue, 16 Sep 1997 01:00:49 +0200 (CEST) From: Mikael Karpberg <karpen@ocean.campus.luth.se> To: tlambert@primenet.com (Terry Lambert) Cc: hackers@FreeBSD.ORG Subject: Re: Memory leak in getservbyXXX? Message-ID: <199709152300.BAA03577@ocean.campus.luth.se> In-Reply-To: <199709150707.AAA16919@usr04.primenet.com> from Terry Lambert at "Sep 15, 97 07:07:28 am"
next in thread | previous in thread | raw e-mail | index | archive | help
According to Terry Lambert: > > Not freeing the memory you allocate is really Bad. Exceptions ofcourse, > > where malloc() is a given. Static buffers in libraries are ugly, true. > > But it gives a very nice (simple) interface. And most of all, that's how > > the standard looks. And there's not a whole lot we can do about it. > > The threading interface and the non-threading interface should be > the same. On that, I think we agree. Yes. > But we are now at odds with the standard because of this, since > POSIX threading specified the _r functions behavioral differences > in like of threading. > > One possibility is to provide a set of library routines that take > a user buffer and fill it in. Yes, that's a possiblity, and I think many wants the _r functions too. Which leads to double code (not double source, neccesarily though) or the need to call a function from a function, which gives another prob. How do you avoid double functioncall-time per call? Maybe you don't. You can probably live with that, though, specially if the functions are close to eachother. See my next comment also. > Provide legacy compatability with inline functions that use > static buffers as the argument to the real functions. This > immediately buys the functions into being threadsafe as well, since > each reference instance will have its own buffer. Is it possible to use a static buffer in an inline function? That means that it's either in one place and all references use it, or that it's a static buffer in each reference, I guess. Neither is threadsafe. Wrapper functions (inline or not) have some problems: 1) can't return a stack-allocated space (except possibly with some gcc quirk) 2) can't use static buffers because it's not thread safe. 3) can't use malloc to get a buffer because then they are allocating but not taking care of freeing themselfs. Basically the only solution I can see to do it (no matter if you don't have *_r calls, if you call them from wrappers, or if you double the code), is to use TSD. And a TSD pointer to a malloc()ated structure which holds all the buffers seems like the fastest and safest way to do it. > Alternately, provide a posix.o in the libc.a archive that contains > unsafe stub functions. > > The threading can be done the POSIX way, where space is allocated, > used as an argument to the refexive functions, and returned, or > it can be done your way, where stub functions allocate thread > local storage onces there's such a thing as thread local storage > that can be mapped into the same location regardless of address > space. The TLS doesn't need to be mapped into the same address space, but can be. It doesn't matter since the info in the TLS will only be a single pointer, which should never be referenced outside the library, and never passed between threads inside the library. The struct itself is allocated outside TLS, but kept track on by a TLS pointer. > In general, except for compatability stub functions, externally > exported static or global data does not belong in libraries. > > > In C++ you > > can get the same nice interface, but without static buffers. You simply > > return string-class objects, etc, instead of a char * to a static buffer. > > But we're not talking C++ interface here. We're talking libc. > > It's possible to provide dynmaic scoping in C as well. It's just > high overhead. Just as it is in C++. Which is one of the reasons > the kernel isn't written in C++. But it *is* possible. Er... What is dynamic scoping? And passing objects back relies on ctors/dtors which C doesn't have. You can write almost everything in C that you can in C++ without changing the structure of the program, but it requires macros and/or extra work by the programmer, which can't be expected of him (like calling destructors by hand, which can be forgotten). [ don't have time for more right now, and FreeBSD changing standards? Likely. ] Anyone else care to comment except Terry? And Terry, you did much better now than with your last mail staying on track. :-) /Mikael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709152300.BAA03577>