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

Jonathan Wakely cow@compsoc.man.ac.uk
Thu Feb 17 14:11:00 GMT 2005


On Thu, Feb 17, 2005 at 11:22:34AM +0000, Jonathan Wakely wrote:

> 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.

Would something like the following avoid the undefined behaviour of
downcasting basic_filebuf* to my_filebuf* in the GCC 3.4 case ?

    typedef std::basic_filebuf<charT, traits> filebuf_t;
    struct crack_filebuf : public filebuf_t {
        // Note: _M_file is of type __basic_file<char> which has a
        // FILE* as its first (but protected) member variable.
        ptrdiff_t offset() const
        { return (char*)&this->_M_file - (char*)(filebuf_t*)this; }

        FILE* c_file(filebuf_t* fb)
        { return *(FILE**)((char*)fb + offset()); }
    };
    FILE* c_file = crack_filebuf().c_file(bbuf);

If that code's legal then that means that there are legal ways of getting
the fd for all valid types in libstdc++ 3.4.2 and up.

The rest of the complication is to deal with other library versions.
That code will never be possible to simplify by making enhancements to
current libstdc++.

jon


-- 
"the chances of finding out what really is going on are so absurdly
remote that the only thing to do is to say hang the sense of it and just
keep yourself occupied"
    - Slartibartfast, "Hitch-Hiker's Guide to the Galaxy"



More information about the Libstdc++ mailing list