Travis Vitek wrote:
Martin Sebor wrote:
Here's a list of all failing tests with 4.2.0 and 4.2.1, with
backward and forward binary compatibility runs included in the
second and third columns. Cells with n/a indicate that the test
wasn't available in 4.2.0. Cells with A### indicate the number
of failing assertions.
The failures in 21.string.replace, 22.locale.numpunct.mt, and
22.locale.messages are possible sources of concern. The COMP
failure in 26.valarray.cassign is a known problem that I plan
to fix by deleting the test from 4.2.1.
I hate to be Captain Obvious here, but...
I thought that we had to maintain both forward and backward binary
compatibility for 4.2.1 and that binary compatibility included
functional compatibility. If that is what we are expecting doesn't that
mean that the failures below are breaking?
No. (You did give a quite a scare for a minute there! These are
all regression tests, so they abort on the old, buggy behavior.
Changing behavior in a patch release is okay if the original
behavior is undefined or buggy (as always, there are going to
be exceptions).
The only one we might want to look into is 22.locale.messages,
but even that one, I suspect, is okay (most likely the result
of STDCXX-607).
Martin
gcc 3.4.3/RHEL 4.4/12D SRC: 4.2.0 4.2.0 4.2.1 4.2.1
LIB: 4.2.0 4.2.1 4.2.0 4.2.1
21.string.io.stdcxx-250 n/a n/a ABRT 0
21.string.stdcxx-231 n/a n/a ABRT 0
22.locale.codecvt.stdcxx-435 n/a n/a ABRT 0
22.locale.messages 0 0 HUP 0
22.locale.num.put.stdcxx-2 n/a n/a ABRT 0
27.basic.ios.copyfmt.stdcxx-766 n/a n/a ABRT 0
27.filebuf.members.stdcxx-308 n/a n/a ABRT 0
27.ostream.unformatted.stdcxx-626 n/a n/a ABRT 0
27.stringbuf.overflow.stdcxx-795 n/a n/a ABRT 0
If the user compiles an app with 4.2.1 and then rolls back to the 4.2.0
library they should expect everything to work, right? That would suck if
their aborted or hung on them like the above test are doing.
Travis
