The patch for PR libstdc++/14097.

[KRECKEL Richard NGLTD]

Hi!

[...]
> Humm... If you refer to std::cout, std::cin, std::cerr; why don't you
> just use the well-known fds 0, 1, 2?

Because an existing interface allows me to pass a reference to an istream
object, nothing else.  That could actually be an ifstream or it could be
cin or whatnot.  In my application, I have to take different paths, based
on whether the stuff I am reading from the istream object comes from a
terminal or not.  This is what isatty(int fd) is good for.  See, fd
*could* be 0, but it could also be 5.

This is just one example.  There is tons of other useful functionality 
defined in SystemV, X/OPEN, BSD and so on which works with fd or FILE* and
which has no correspondence in ISO C++ whatsoever.  We cannot just ditch
half of Unix simply by pointing out that we are living in a higher
abstraction sphere.

There are people out there who want to program C++ on Unix-like systems.
They are not interested in portability to non-Unix, but still they might
be interested in portability across different flavors of Unix including
GNU/Linux.  Artificially detaching the two layers forces some of them to
abandon C++ IOstreams and fall back to the bronze age.

> You will note that ext/stdio_sync_filebuf.h wraps FILE-level support to
> sync with the libc stdio (this is a requirement of the standard in the
> default mode of operation) and that ext/stdio_filebuf.h wraps FD-level
> support when sync to libc stdio is not required.  We only expose the FD
> when we wrap that layer.

Then, for reasons of symmetry, we should expose the FILE* when we wrap the
other layer.  Like this:

--- gcc-3.4-20040206.orig/libstdc++-v3/include/ext/stdio_sync_filebuf.h
2003-12-09 05:31:53.000000000 +0100
+++ gcc-3.4-20040206/libstdc++-v3/include/ext/stdio_sync_filebuf.h
2004-02-11 10:49:48.000000000 +0100
@@ -81,6 +81,16 @@
       : _M_file(__f), _M_unget_buf(traits_type::eof())
       { }

+      /**
+       *  @return  The underlying FILE*.
+       *
+       *  This function can be used to access the underlying C file
pointer.
+       *  Note that there is no way for the library to track what you do
+       *  with the file, so be careful.
+      */
+      FILE*
+      c_file()
+      { return this->_M_file; }
     protected:

       int_type

>                           The fact that we expose any of this concrete
> detail as an extension boggles the mind...

For the record, I have to disagree.  And it seems I am not alone.  Quoting
from <http://gcc.gnu.org/ml/libstdc++/2001-09/msg00057.html>: "On UNIX-like
systems, there should be a way to get a file descriptor from an stream,
in the cases where there really is an underlying descriptor."

Regards
    -richy.
-- 
Dr. Richard B. Kreckel
Framatome ANP GmbH, NGLTD
<Richard.Kreckel@Framatome-ANP.COM>