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