[iostreams] Is anyone maintaining Boost.IOStreams?
From a quick scan, it looks like this library is not being
I've just looked through the list of bugs for the iostreams library: https://svn.boost.org/trac/boost/report/14?USER=anonymous&page=4 maintained any more. Is this true? Just scratching to scratch the surface, the following dozen bugs seem to be to all be trivial to fix. Many have patches, and the others have a sufficiently clear description that fixing them should only be a couple of minutes' work. 2094 -- has a patch that ought to be uncontroversial 2154 -- relates to code that seems not to exist any longer 2817 -- proposed resolution seems straightforward 2894 -- seems pretty straightforward 2932 -- would be trivial to fix, assuming a fix is desired 3010 -- appears to have been fixed 3011 -- has a patch that ought to be uncontroversial 3197 -- trivial suggestion to remove a compiler warning 3311 -- obviously an error and trivial to fix 3352 -- looks like a genuine subtle bug; includes a patch 3403 -- minor documentation niggle, complete with patch 3505 -- looks a genuine bug and includes patches Some of the other bugs look pretty serious to me, and I might be inclined to spend some time investigating them if I thought there was any realistic chance of the resulting patches being accepted. -- Richard Smith
2009/11/11 Richard Smith <richard@ex-parrot.com>:
From a quick scan, it looks like this library is not being maintained any more. Is this true?
Yes. There also some developments in trunk from a while back that haven't been released. I don't know if they're worth keeping or not.
Some of the other bugs look pretty serious to me, and I might be inclined to spend some time investigating them if I thought there was any realistic chance of the resulting patches being accepted.
That'd be great. I'll deal with the patches if no one else does. Daniel
Daniel James wrote:
There also some developments in trunk from a while back that haven't been released. I don't know if they're worth keeping or not.
I think I must be misunderstanding what you mean here. I can only see one change to the libs/iostreams or boost/iostreams directories between the following SVN branches: https://svn.boost.org/svn/boost/trunk https://svn.boost.org/svn/boost/branches/release (That's a trivial change to a $Date:$ RCS tag in libs/iostreams/test/large_file_test.cpp.) Am I looking in the wrong place? -- Richard Smith
2009/11/11 Richard Smith <richard@ex-parrot.com>:
I think I must be misunderstanding what you mean here. I can only see one change to the libs/iostreams or boost/iostreams directories between the following SVN branches:
https://svn.boost.org/svn/boost/trunk https://svn.boost.org/svn/boost/branches/release
(That's a trivial change to a $Date:$ RCS tag in libs/iostreams/test/large_file_test.cpp.)
Am I looking in the wrong place?
No, my mistake, it was a little while ago when I last looked. Beman merged the changes last month. Daniel
Richard Smith wrote:
Just scratching to scratch the surface, the following dozen bugs seem to be to all be trivial to fix.
Yes!
Some of the other bugs look pretty serious to me, and I might be inclined to spend some time investigating them if I thought there was any realistic chance of the resulting patches being accepted.
Me too! Best regards, Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards
On Wed, Nov 11, 2009 at 9:05 AM, Richard Smith <richard@ex-parrot.com>wrote:
I've just looked through the list of bugs for the iostreams library:
https://svn.boost.org/trac/boost/report/14?USER=anonymous&page=4
From a quick scan, it looks like this library is not being
maintained any more. Is this true? Just scratching to scratch the surface, the following dozen bugs seem to be to all be trivial to fix. Many have patches, and the others have a sufficiently clear description that fixing them should only be a couple of minutes' work.
2094 -- has a patch that ought to be uncontroversial 2154 -- relates to code that seems not to exist any longer 2817 -- proposed resolution seems straightforward 2894 -- seems pretty straightforward 2932 -- would be trivial to fix, assuming a fix is desired 3010 -- appears to have been fixed 3011 -- has a patch that ought to be uncontroversial 3197 -- trivial suggestion to remove a compiler warning 3311 -- obviously an error and trivial to fix 3352 -- looks like a genuine subtle bug; includes a patch 3403 -- minor documentation niggle, complete with patch 3505 -- looks a genuine bug and includes patches
Some of the other bugs look pretty serious to me, and I might be inclined to spend some time investigating them if I thought there was any realistic chance of the resulting patches being accepted.
2817 would be a really, really helpful fix, for me anyway.
Zachary Turner wrote:
2817 would be a really, really helpful fix, for me anyway.
It looks like this is fixed in 1.41.0 as part of the refactoring of the file_descriptor class, though I'm not really a Windows expert, so you might want to check. Perhaps #2817 could be added to the list of 'various other fixes' in the 1.41.0 release notes? Richard
On Wed, Nov 11, 2009 at 6:34 PM, Richard Smith <richard@ex-parrot.com>wrote:
Zachary Turner wrote:
2817 would be a really, really helpful fix, for me anyway.
It looks like this is fixed in 1.41.0 as part of the refactoring of the file_descriptor class, though I'm not really a Windows expert, so you might want to check. Perhaps #2817 could be added to the list of 'various other fixes' in the 1.41.0 release notes?
I'm not familiar with the release / SVN procedures, can you point me to where in the SVN repository this would be? There's only headers file, I don't see the cpp corresponding to file_descriptor.hpp
Zachary Turner wrote:
I'm not familiar with the release / SVN procedures, can you point me to where in the SVN repository this would be? There's only headers file, I don't see the cpp corresponding to file_descriptor.hpp
The header and source files are here: https://svn.boost.org/trac/boost/browser/branches/release/boost/iostreams/de... https://svn.boost.org/trac/boost/browser/branches/release/libs/iostreams/src... Richard
On Wednesday 11 November 2009 04:05:52 pm Richard Smith wrote:
I've just looked through the list of bugs for the iostreams library:
https://svn.boost.org/trac/boost/report/14?USER=anonymous&page=4
From a quick scan, it looks like this library is not being maintained any more. Is this true?
Looks like it to me.
3010 -- appears to have been fixed
I wrote this ticket. It is not resolved. The ticket is against a change in trunk that is not merged to release. A more important question is if all the other trunk changes make sense to merge by anybody just on regression test results. What is the rationale for then, where is the library heading, ... Somebody would have to dig in a bit to assess if the changes should be merged to release. It seems logical at this point to attempt to contact the listed maintainer and resent committers and request their intentions to maintain Boost.iostreams. If there is no intentions to continue, request others to maintain the library actively. If that fails, put the trunk changes in a branch and sync trunk with release. From that point it should be possible to at least get some fixes into release. -- Bjørn
Bjørn Roald wrote:
3010 -- appears to have been fixed
I wrote this ticket. It is not resolved.
Apologies. You're quite right.
The ticket is against a change in trunk that is not merged to release.
It has been now -- the version without the include guard looks like it will be in 1.41.0. (In fact, everything in trunk has recently been merged to release.)
A more important question is if all the other trunk changes make sense to merge by anybody just on regression test results. What is the rationale for then,
Many of the changes are purely cosmetic -- for example, changing various private typedefs from policy_type to something more descriptive, or reordering members into a more logical order. Richard
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
2009/11/12 Richard Smith <richard@ex-parrot.com>:
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.
It's fine, you probably know by now that I've commited them. I gave them a fairly cursory review first. I'll merge to release when it opens for 1.42 if the regression tests look good. You could probably get subversion access if you wish, the details are at https://svn.boost.org/trac/boost/#GettingaTracSVNUserid
2094 -- has a patch that ought to be uncontroversial
This is all about -fno-exceptions support. How much do we actually care about this?
Some people care, but support is patchy.
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?
I don't think so. I just use RAII. Daniel
participants (5)
-
Bjørn Roald -
Daniel James -
Richard Smith -
Sylvester-Bradley, Gareth -
Zachary Turner