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