Re: [boost] [iostreams] Is anyone maintaining Boost.IOStreams?

Subject: Re: [boost] [iostreams] Is anyone maintaining Boost.IOStreams?
From: Richard Smith (richard_at_[hidden])
Date: 2009-11-11 21:25:21

Richard Smith wrote:

> Just scratching to scratch the surface, the following 
> dozen bugs seem to be to all be trivial to fix.

I have produced a patchset against svn trunk for all of 
these bugs.

http://ex-parrot.com/~richard/tmp/boost_iostreams_patches_20091111.tar.gz

(They're arranged so that you can apply them all using 
quilt; if you don't use quilt, the series file specifies the 
order they need applying in.)

If this is a convenient way of doing things, I can move on 
to some of the more involved bugs next.

Details follow.

>  2094 -- has a patch that ought to be uncontroversial

This is all about -fno-exceptions support.  How much do we 
actually care about this?  I have a patch that wraps up all 
throw statements using boost::throw_exception, but this 
still leaves rethrow (i.e. plain 'throw;' statements) and 
try/catch blocks that need to be wrapped up if we want a 
clean GCC compile with -fno-exceptions.  Does Boost have a 
standard way of doing this?

>  2154 -- relates to code that seems not to exist any longer

The last trace of this is libs/iostreams/src/file_times.cpp 
-- this file is unused and needs removing.

>  2817 -- proposed resolution seems straightforward

Actually, it seems to already be fixed on release.  See 
previous email.

>  2894 -- seems pretty straightforward

I believe I haved fixed this, but I've only tested it on 
a machine where sizeof(std::streamsize) == sizeof(int).

>  2932 -- would be trivial to fix, assuming a fix is desired

Already fixed on 1.41.0.

>  3010 -- appears to have been fixed

Per previous email, I was mistaken about it being fixed. 
The patch in the ticket applies cleanly.

>  3011 -- has a patch that ought to be uncontroversial

The patch in the ticket applies cleanly.

>  3197 -- trivial suggestion to remove a compiler warning

Fixed on 1.41.0.

>  3311 -- obviously an error and trivial to fix

I have a patch for all of the instances of this that I can 
find.

>  3352 -- looks like a genuine subtle bug; includes a patch

The patch from the bug applies applies cleanly. 
Unfortunately, I don't have a system on which I can 
reproduce the bug.

>  3403 -- minor documentation niggle, complete with patch

Still relevant.

>  3505 -- looks a genuine bug and includes patches

Patch no longer applies due to refactoring, but issue still 
applies.  Assuming the documentation in

http://msdn.microsoft.com/en-us/library/aa366537%28VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx

is accurate, CreateFile does indeed return 
INVALID_HANDLE_VALUE on error, while CreateFileMapping 
returns NULL.  I have a new patch for this, but would 
welcome input from someone more expert with Windows.

Richard