Re: filebuf::fd()

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

> 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.

Agreed.  We should only expose the pointer type as used by the library
itself.  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.

> 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.

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).

> 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?

Regards,
Loren