The patch for PR libstdc++/14097.

[Gabriel Dos Reis]

Loren James Rittle <rittle@latour.rsch.comm.mot.com> writes:

| Richard,
| 
| Your line of argument [removed here] and patch below seems reasonable
| to me.  Is there anyone associated with the change in concrete
| stdio*filebuf<> implementation(s) that disapproves strongly?
| 
| > Then, for reasons of symmetry, we should expose the FILE* when we wrap the
| > other layer.  Like this: [...]
| 
| >> 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."
| 
| Yet note that Zack and Mark make the exact same point as I about GNU
| compiler extensions... ;-) Users complain when we change the concrete
| implementation and that it breaks their usage of undocumented APIs
| (granted your request is not very outrageous so please understand the
| general point here).

I make a strong reservation too.

The point is not ignoring Unix programming.  The whole point is
whether you have to make an extension under the gun, and if so what
latitude do you have to change things later when I get a better idea
than when you were undr the gun.  
I can't argue with arguments saying that Unix programming has been
around for long time. However, I disagree with the line of reasoning
building on that and saying the C++ style ought to use the same
abstractions as C.  I know what the problems are, but I also believe
that if you've been using the C abstractions for a while, then you can
just continue to use them without requiri ng mucking around with the C
abstractions  

I'm all for a stream library extension that integrates the more
elaborated POSIX notion, but I'm not sure I'll vote "yes" for the kind
of things going around here.

-- Gaby