Re: Accessing the UNIX file descriptor inside an fstream

[Scott Johnston <scott at accom dot com>]

I have converted a good deal of Unix C++ iostreams software from
libstdc++-V2 to libstdc++-V3, and the only thing that was troublesome
was the lack of filebuf::filebuf(int fd) and filebuf::fd().

The filebuf(FILE*) constructor (in conjunction with fdopen()) was
useful,
but there are some hidden problems.  For instance, doing an fclose() on
a
FILE* created by fdopen() closes the underlying file descriptor as well.

This makes it difficult to open an istream to handle a portion of socket
input
(which some of this code did).  You either have to defer all the
fclose's, or
rewrite to use a single istream object, something that wasn't necessary
with previous support for file descriptors in libstdc++-V2.

When we  originally created this software (which makes extensive use of
pipe() and dup(), etc..) we had no way of knowing that filebuf would get

divorced  from  fd's in the future, and we made some hard-to-reverse
architectural decisions that rely on filebuf::filebuf(fd).  I feel
somewhat
foolish for not doing the ultra-conservative thing and sticking to
C-style
I/O.

Phil Edward's has stated that in his opinion fd-related extensions to
filebuf
are out of the question, because the software does not know about the
underlying file descriptors.  But the software could be made to know
about
this, at least for POSIX copies of libstdc++-V3.

I understand there might be synchronization issues that crop up using
different kinds of I/O objects simultaneously (FILE*'s, file
descriptors,
iostreams).   There certainly were with libg++ and earlier libstdc++'s.
But these can be solved like they were in the past.  And there is plenty
of legacy software (and legacy programmers) available for testing
purposes.

Phil also states that non-POSIX programmers would be bothered to see
file  descriptors exposed.  Can it really be true that there are
implementations of C (or C++) that exclude the K&R's I/O layer of
read/open/creat on disk  files?  Isn't the real issue that some OS'es
use
something other than a file descriptor for sockets, and only unify
sockets
and file handles in a FILE*?

Personally I can handle a #ifndef WIN32 around all my use of
filebuf::filebuf(int fd) in a socket context, as is typically required
for many
cross-platform programming activities when you drift from a POSIX
standard.  Others can avoid using these extensions or won't find them on
their non-POSIX OS.

Blame it on Per if you have to.  But can you please give us our filebuf
fd
support again?

Respectfully, Coordially, and Gratefully Yours,

Scott Johnston
http://www.ivtools.org