>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? > >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
