Re: feb-2002 libstdc++ outstanding

[Benjamin Kosnik <bkoz at redhat dot com>]

> > Yeah. This, filebuf::fd, and filebuf::(special ctors) are all on my 
> > "to-review ASAP" list. I think a better approach is the Dietmar way.
> 
> What's the difference?  I'm looking at src/sysfile.cpp of his cxxrt
> implementation.  He uses 0777 instead of our 0664, but it's still hardcoded.

Sorry, I wasn't very clear. I was attempting to point out that instead of 
cramming extra bits into basic_filebuf, it is now my belief that 
libstdc++ should be using derived classes for all non-standard 
filebuf-related functionality. This is a departure from current practice, 
but one that I think is best in the long run.

At the moment, this includes filebuf::fd. There are a lot of requests for 
a fd-based filebuf ctor. There is a non-standard FILE* filebuf ctor. 
There are requests for setting permissions on newly created files.
Etcetera, etcetera, etcetera. 

I did both a derived and a hacked-filebuf version of encoding-variable 
filebufs when implementing wide io, so that encodings can be set on a 
per-filebuf basis. At the time I posted the derived classes I was using, but 
didn't really go into details. I became convinced that the derived 
approach is the biggest win at that time. 

I'm not really in a position to give a more complete answer right now, as 
I'm trying to solve the one remaining linux fail.  I hope to give a more 
compelling analysis in a week or so, at which point hopefully this will 
be less murky.

-benjamin