This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Legalize access to file descriptors now! (So sue me.)


On Wed, Feb 16, 2005 at 11:56:29PM +0100, Richard B. Kreckel wrote:
> Since we've had the discussion whether to allow access to file descriptors
> from C++ stream objects more than once without any result, I've had to
> hack my way through to the file descriptors by applying a good amount of
> brute force (not to mention all the beer).
> 
> So, here is my lament: http://www.ginac.de/~kreckel/fileno/.  Could you
> folks please, please make the access a little bit more smooth?  We need
> the
> file descriptor.  We are going to get it.  Don't prolong the agony.

We need it, and we get it with a tiny class I first posted in
<http://gcc.gnu.org/ml/libstdc++/2004-04/msg00146.html>.  It hasn't
proven too painful for us.  I even use it to keep something open and
force some things closed when fork()ing.  Granted, I don't need it on
_every_ stream.  Anyway, for what it's worth, here's one approach.

// This class exposes the UNIX file descriptor that is beneath the IO
// Streams filebuf.
class fdfilebuf : public std::filebuf
{
  typedef std::filebuf base;
  
public:
  fdfilebuf()
    : base()
  {}
  
  virtual ~fdfilebuf()
  {}
  
public:
  // Our purpose in life is to return the UNIX file descriptor.  This is an
  // extension that is made possible by some knowledge of the underlying
  // IO Streams implementation and is not supported as an interface in that
  // implementation. 
  int fd()
  {
    // _M_file is a protected member of our base class, and it knows the real
    // file descriptor.
    return _M_file.fd();
  }
};

>From that point on, it's a little weird to get it in place, but not so
terrible with a known-to-be-newly-constructed stream.  I haven't
tried, but perhaps it is possible to derive from std::ofstream (for
example) and do all of that automatically, and even add the fd()
member to the stream itself.  That way, it'd be obvious which streams
you can fd() and which you can't.

To me, it makes sense that this extension is just that: an extension
to the IO Streams hierarchy, and thus contained and controlled.  It
might be possible to do the reverse trick (use an existing fd) by
swapping in another user filebuf.

Getting the fd is implementation-specific, but it has to be, since the
fact that there's a file descriptor to get is an implementation detail
anyway.  If you needed to support multiple implementations, you could
chose the appropriate implementation of the fd() member function, if
it even made sense.

I've trimmed down the example in my original post to show a simple
case without any syslog stuff and without support for re-opening the
stream.  It's attached.

-- 
------------------------------------------------------------------
Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
Systems Architect | InfoInterActive Corp. | A Canadian AOL Company

Attachment: sample.cc
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]