Entire iostreams library outdated in 1.34.0

[Kim Barrett <kab@…>]

A significant number of changes were made to the boost.iostreams library on the RC_1_33_0 branch, but never merged into the trunk.

There are also a few changes on the RC_1_34_0 branch that have not been merged to into the trunk.

There has also been some work on the trunk, some of which is on one of those branches, a few cases of merges between one of those branches and the trunk, and I found at least one case of apparent merging with code rearrangement or other changes (at least, diff seemed to not match up the (similar by eye) changes).

So basically there is a bit of a mess in the iostreams library. Here's what I think needs to happen:

• changes that are presently only on the RC_1_33_0 or RC_1_34_0 branch should be merged to trunk

• changes that are presently only on the RC_1_33_0 branch should be merged to the RC_1_34_0 branch.

Attached is a gzip'ed tar file containing two patches, one for trunk and one for the RC_1_34_0 branch.

• kab-iostreams-trunk.patch: This patch merges changes to the iostreams library from the RC_1_33_0 and the RC_1_34_0 branches to the trunk. It was generated relative to a cvs checkout of trunk at date -D 2007.05.14.22.34.09.

• kab-iostreams-RC_1_34_0.patch: This patch brings the iostreams library to the same state as trunk + the above patch to trunk. It was generated relative to a cvs checkout of tag Version_1_34_0.

These patches are both made relative to the boost root directory. To apply, cd to the root directory of the copy to be patched and

patch -p1 < <path/to/patch>

The kab-iostreams-RC_1_34_0.patch has been tested on the following platforms by myself (linux) or John Maddock (other), with the indicated results:

• linux-x86-gcc_4_1: debug mode: no failures in iostreams tests
• linux-x86-gcc_4_1: release mode: no failures in iostreams tests
• linux-ppc-gcc_3_4_4: debug mode: no failures in iostreams tests
• msvc6, msvc7.0: one failure in iostreams tests, marked expected for RC_1_34_0
• msvc-7.1, msvc-8: no failures in iostreams tests
• intel-8.1, intel-9: no failures in iostreams tests
• gcc-3.4-cygwin: 3 failures in iostreams tests, all marked expected for RC_1_34_0
• borland-5.8.2: 1 failure in iostreams tests, marked expected for RC_1_34_0
• borland-5.6.4: 2 failures in iostreams tests, not a release compiler for RC_1_34_0, one failure marked expected in newer borland-5.8.2 compiler

I've done some spot-checking of the documentation changes and haven't found any problems.

The trunk patch has not bee tested, beyond verifying that the iostreams library is in the same state for sandboxes on trunk and the RC_1_34_0 branch after application of the appropriate patch. Since testing resources have been focused on the release branch for a while, I have no idea what state trunk might be in; for all I know, trunk doesn't actually build at the moment.

[Kim Barrett <kab@…>]

The test results got misformatted in my in original submission. Here they are again, hopefully more readably:

• linux-x86-gcc_4_1: debug mode: no failures in iostreams tests

• linux-x86-gcc_4_1: release mode: no failures in iostreams tests

• linux-ppc-gcc_3_4_4: debug mode: no failures in iostreams tests

• msvc6, msvc7.0: one failure in iostreams tests, marked expected for RC_1_34_0

• msvc-7.1, msvc-8: no failures in iostreams tests

• intel-8.1, intel-9: no failures in iostreams tests

• gcc-3.4-cygwin: 3 failures in iostreams tests, all marked expected for RC_1_34_0

• borland-5.8.2: 1 failure in iostreams tests, marked expected for RC_1_34_0

• borland-5.6.4: 2 failures in iostreams tests, not a release compiler for RC_1_34_0, one failure marked expected in newer borland-5.8.2 compiler

I've also now checked that the failures reported for msvc6/msvc7.0 and for borland-5.6.4 were also failures for the 1.33.1 release. The failures from the borland-5.8.2 and gcc-3.4-cygwin compilers can't be compared with 1.33.1 results because those compilers aren't present in the 1.33.1 results.

[anonymous]

It's likely that this supercedes Ticket #955 as well.