Date: Tue, 4 Jan 2005 05:00:41 GMT From: "Ronald F. Guilmette" <rfg@monkeys.com> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/75767: WANTED: "fdclose" function in libc Message-ID: <200501040500.j0450fOY044877@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/75767; it has been noted by GNATS.
From: "Ronald F. Guilmette" <rfg@monkeys.com>
To: Giorgos Keramidas <keramida@freebsd.org>
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.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200501040500.j0450fOY044877>