Building Tests
I haven't looked to confirm this but it looks like the Makefile(s) ignore errors building the test programs but the build process still stops (i.e. exits successfully). I was wondering if the Makefile(s) shouldn't also continue building the remaining test programs (i.e. set MAKEFLAGS=-k before invoking the test Makefile). Brad.
[STDCXX-709] ContainerData ctor and UserClass::from_char()
So I'm stepping through the ContainerTestCaseData (const ContainerFunc func, const ContainerTestCase tcase) constructor as shown in the following stack frame: (gdb) where #0 ContainerTestCaseDataUserClass::ContainerTestCaseData (this=0x7fffe750, [EMAIL PROTECTED], [EMAIL PROTECTED]) at /amd/devco/lemings/work/stdcxx/trunk.gofish/tests/include/23.containers. h:280 Here's part of the ctor: (gdb) list 276 char buf [256]; 277 278 strlen_ = sizeof (buf); 279 char* str = rw_expand (buf, tcase.str, tcase.str_len, strlen_); 280 str_ = T::from_char (str, strlen_); 281 if (str != buf) 282 delete[] str; Notice anything unusual around line 280? Here's a hint: tests/include/rw_value.h: 228 // construct an array of objects of type UserClass each initialized 229 // from the corresponding element of the character array 230 // when the last argument is true and the character array 231 // is not sorted in ascending order the function fails by 232 // returning 0 233 static UserClass* 234 from_char (const char*, _RWSTD_SIZE_T = _RWSTD_SIZE_MAX, 235 bool = false); Now I'm sorta new to this UserClass and container testing but but WTF is going on here? char* and UserClass* are convertible certainly but clearly not compatible. Brad.
RE: [STDCXX-709] ContainerData ctor and UserClass::from_char()
-Original Message- From: Eric Lemings [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2008 2:36 PM To: dev@stdcxx.apache.org Subject: [STDCXX-709] ContainerData ctor and UserClass::from_char() ... Now I'm sorta new to this UserClass and container testing but but WTF is going on here? char* and UserClass* are convertible certainly but clearly not compatible. Ehh, darn. I got str and str_ mixed up. Anwyays, what does this have to do with STDCXX-709? I believe the _rw_find_block() function is not able to find the specified memory block because the array is initially allocated by the __rw_from_char() function (file tests/src/value.cpp, line 485) and therefore is not mananging this memory in its headers. So either a new handler needs to be added or the delete replacement needs to be removed. If anyone can verify this analysis is correct, please do. :) Brad.
RE: 4.2.1 platforms
IBM dropped support for Visual Age 6 last spring. So while you all may want to support it as a best effort platform, it probably shouldn't be a secondary platform. I could state many reasons, but suffice it to say that IMHO MSVC 7.1 should also be on the best effort list. Thoughts? -- Tim -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Thursday, March 20, 2008 10:08 AM To: dev@stdcxx.apache.org Subject: 4.2.1 platforms Here's my proposed list of platforms for 4.2.1. I don't think we can quite meet the release goals outlined in the release policy (I don't see us cleaning up all the test failures and warnings on all Primary platforms) but we might as well try to use the process to the extent we can. Let me know if I've missed something. Once we have the final list I'd like to open a vote on it. Primary: HP aCC 6.16/HP-UX HP aCC 3.74/HP-UX gcc 3.4, 4/Linux Intel C++ 10/Linux/Windows MSVC 8.0, 9.0/Windows Sun C++ 5.9/Solaris XLC++ 9.0/AIX Secondary: EDG eccp 3.9/Linux gcc 3.2/Linux gcc 3.4/FreeBSD Intel C++ 9.1/Linux/Windows MSVC 7.1/Windows Sun C++ 5.9/Linux Sun C++ 5.8, 5.7/Solaris XLC++ 8.0, 7.0/AIX 5 VisualAge 6.0/AIX 5 Best Effort: EDG eccp 3.9/Solaris gcc 4/Darwin HP C++ /Tru64 UNIX 6.5 MIPSpro 7.41/IRIX 6.5 Sun C++ 5.3/Solaris
RE: [STDCXX-709] ContainerData ctor and UserClass::from_char()
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2008 3:32 PM To: dev@stdcxx.apache.org Subject: Re: [STDCXX-709] ContainerData ctor and UserClass::from_char() ... So you think there's a mismatch between the allocation function invoked in value.cpp and the deallocation function called in the header? Why would that be? IIUC, tests that replace operator new and operator delete (such as 23.list.assign) replace it for the whole process. If there's a mismatch, it can only be because the operators aren't replaced consistently. Making sure this replacement happens across the whole process, including any libraries, is the responsibility of the C++ runtime (i.e., the compiler). If your analysis is correct, the C++ runtime on IPF would have to be buggy. Or did I misunderstand what you were trying to say? Sounds about right. I just noticed there's a runtime link error in the config test OPERATOR_NEW_ARRAY_PLACEMENT on HP-UX IPF platforms. May be the culprit. [EMAIL PROTECTED] ./include/OPERATOR_NEW_ARRAY_PLACEMENT /usr/lib/hpux32/dld.so: Unsatisfied code symbol '_ZnamPv' in load module './stdcxx/include/OPERATOR_NEW_ARRAY_PLACEMENT'. Killed Brad.
Re: Building Tests
Eric Lemings wrote: I haven't looked to confirm this but it looks like the Makefile(s) ignore errors building the test programs but the build process still stops (i.e. exits successfully). I was wondering if the Makefile(s) shouldn't also continue building the remaining test programs (i.e. set MAKEFLAGS=-k before invoking the test Makefile). I don't think the makefiles ignore build errors. The only processes that continue after errors is configuration and the run target. And of course, in nightly builds we ignore all but library build errors by explicitly invoking make with -k as you said. Martin
