From owner-freebsd-bugs@FreeBSD.ORG Tue Jan 4 05:00:42 2005 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17C1516A4D0 for ; Tue, 4 Jan 2005 05:00:42 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D393943D2F for ; Tue, 4 Jan 2005 05:00:41 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0450fdd044878 for ; Tue, 4 Jan 2005 05:00:41 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0450fOY044877; Tue, 4 Jan 2005 05:00:41 GMT (envelope-from gnats) Date: Tue, 4 Jan 2005 05:00:41 GMT Message-Id: <200501040500.j0450fOY044877@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: "Ronald F. Guilmette" Subject: Re: bin/75767: WANTED: "fdclose" function in libc X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Ronald F. Guilmette" List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2005 05:00:42 -0000 The following reply was made to PR bin/75767; it has been noted by GNATS. From: "Ronald F. Guilmette" To: Giorgos Keramidas Cc: bug-followup@freebsd.org Subject: Re: bin/75767: WANTED: "fdclose" function in libc Date: Mon, 03 Jan 2005 20:59:48 -0800 In message <20050104003813.GF45341@gothmog.gr>, you wrote: >I believe there is no easy way to fdclose() a FILE object _and_ do it in >a way that would satisfy all the potential uses of such a function. I didn't request something that would ``satisfy all of the potential uses of such a function''. My goals are not nearly so gradiose, and my need is a very simple one. >Some of the problems that an implementation would have to face are >immediate results of the buffered nature of FILE streams: > > a) Should any pending writes be flushed out before the FILE object is > destroyed? Please see my PR. I asked for a function that would do everything that fclose() does _except_ for calling close() on the underlying file. > b) What should the implementation do with any data that has been > "read-ahead" and cannot be pushed back to an input stream? Please see my PR. I asked for a function that would do everything that fclose() does _except_ for calling close() on the underlying file. >I don't think there is a Right Thing(TM) for all the possible cases. Of course there isn't. That's why I didn't ask for anything that would do the ``Right Thing(TM) for all the possible cases''. Nothing and nobody can satisfy everyone. A hammer is no good for unscrewing screws. But it is an excelent tool for pounding nails. I own one, and use it frequently for its intended purpose. And I am very glad to have it in my toolbox. >Especially if the FILE object is attached to a device node, which may or >may not support data read-ahead, pushing back of input data, rewinding >on every open(), etc. All of these issues also come up in the case of calling fclose(). And the fclose() library function, whatever its specific semantics may be, has been considered useful by many many programmers, over time, despite the fact that it does not solve every problem for every programmer. (It _does_ solve _enough_ problems for _enough_ programmers to be rightfully a part of libc.) >> Add a new "fdclose" function to libc. This should have the same >> effects as fclose, except that it should *not* close the underlying >> UNIX file descriptor. > >You can probably emulate most of the behavior of fdclose() when such a >need arises with something like this: Actually, since I sent in my PR, I did some more digging in the sources of libc, and I found a much simpler way to get what I want, at least on FreeBSD (however this is quite definitely _not_ portable): file->_close = NULL; fclose (file); (I would still like to see the above functionality turned into a library function however.)