Boost logo

Boost :

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.

(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

> 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

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at