Re: filebuf::fd()

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Mon, Dec 10, 2001 at 04:49:06PM -0600, Loren James Rittle wrote:
> > Gaby and I are of the same opinion:  we should be exposing the same 
> > pointer that the library itself uses as a wrapper layer, and not be
> > making any assumptions about what lies beneath, especially since the
> > library itself never uses a file descriptor.
> 
> ...  Now, consider that this type might change when the file
> backing basic_file.cc changes...  I think any solution worth going in
> the source base must account for this aspect of libstdc++-v3
> configuration unless we want to admit that basic_file_stdio.cc is the
> only valid configuration for basic_file.cc for the foreseen future.

Exactly the point.  To expose a FILE pointer is to expose a very
incidental implementation detail of filebuf.  Among those people
who _want_ access to guts, who has actually asked for a FILE*?  

Note that anybody who does want a FILE* can easily construct one using 
the file descriptor.  If that's not good enough, it implies they want 
access not only to the file descriptor, but to our internal buffers and 
buffer pointers.  Exposing a FILE* is not just a matter of returning
something that fileno() will work on; it implies returning something 
suitable as an argument for anything that takes a FILE*.  We would have 
to promise to accommodate anything might be done to the FILE pointed 
to, or document what is and is not allowed.

A file descriptor has none of these complications, aside from the 
obvious need for a sync() call before using it.

> > Nathan feels we should be doing more work with a file descriptor, that
> > the patch I posted is the right approach, and that "since the library
> > itself never uses a file descriptor" is in fact a bug.  This seems to be
> > more popular.
> 
> When I disagree with Nathan, I usually find a flaw in my own thinking
> given enough time. ;-)  The problem I have with the popular approach is
> that it assumes POSIX and that the current basic_file.cc mapping is
> the only valid one.  If gcc made that assumption then we could remove
> a lot more configuration code.  Thus, I assume that there is still a
> good reason to not assume POSIX is everywhere.

The original AT&T iostream had a filebuf::fd() member.  It was left out 
of the Standard as non-portable.  Adding it back in provides backward 
compatibility with AT&T iostream and with Per's v2.

On platforms that are not POSIX, fd() is meaningless.  Then, you need
something else completely target-dependent.  I suspect the sentiment
in favor of FILE* is meant to chase a portability which is at base
illusory.  The desire for an fd() or something like it is inherently 
unportable, and any alternative which seems to provide portability is
thereby revealed as mistaken.

> If this extension is done right (according to my idea of right), then
> there should be no hard-coded dependency on either FILE* or file
> descriptors in include/bits/fstream.tcc or include/bits/basic_file.h.
> I have no idea if there is a flaw in my thinking but it seems when a
> type is unknown at the time an API is defined, we must use a template:
> 
> template <class HT>
> HT get_raw_handle (iostream& i);
> 
> Under this approach, the application attempts to get a handle of the
> type it needs with, e.g., get_raw_handle<FILE*> (cin).  An exception
> could be thrown if the handle used by the libstdc++-v3 implementation
> is not of that type (perhaps we could also allow conversion from FILE*
> to file descriptor).

A get_raw_handle<>() member on filebuf might be a nice addition.
I don't see its prospect as a reason to leave out important 
backward-compatibility support.
 
> > If we're going to provide this as an extension in 3.1, we need to finalize
> > this before the end of Phase 2, six days from now.
> 
> I know some users want this feature but is any idea baked enough yet?

filebuf::fd() is pretty hard to get wrong.  #ifdefs can be girded round
it at our leisure, in 3.1.x or 3.2.  As a template function, it is not 
compiled unless used, so it should be harmless even where there is no 
definition of fileno() available.

Nathan Myers
ncm at cantrip dot org