[jira] [Updated] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

2012-02-07 Thread Stefan Teleman (Updated) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Teleman updated STDCXX-1056:
---

Attachment: runtests-linux64-all.out

# COMPILER: gcc 4.5.0, __VERSION__ = "4.5.0 20100604 [gcc-4_5-branch revision 
160292]"
# ENVIRONMENT: x86_64/LP64 running linux-elf (openSUSE 11.3 (x86_64)) with 
glibc 2.11
# COMPILED: Feb  7 2012, 21:25:22


> std::moneypunct and std::numpunct implementations are not thread-safe
> -
>
> Key: STDCXX-1056
> URL: https://issues.apache.org/jira/browse/STDCXX-1056
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 22. Localization
>Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
> Environment: Solaris 10 and 11, RedHat and OpenSuSE Linux, Sun C++ 
> Compilers 12.1, 12.2, 12.3
> Issue is independent of platform and/or compiler.
>Reporter: Stefan Teleman
>  Labels: thread-safety
> Fix For: 4.2.x, 4.3.x, 5.0.0
>
> Attachments: 22.locale.numpunct.mt.out, runtests-linux32-all.out, 
> runtests-linux64-all.out, runtests.out, stdcxx-1056.patch
>
>
> several member functions in std::moneypunct<> and std::numpunct<> return
> a std::string by value (as required by the Standard). The implication of 
> return-by-value
> being that the caller "owns" the returned object.
> In the stdcxx implementation, the std::basic_string copy constructor uses a 
> shared
> underlying buffer implementation. This shared buffer creates the first 
> problem for
> these classes: although the std::string object returned by value *appears* to 
> be owned
> by the caller, it is, in fact, not.
> In a mult-threaded environment, this underlying shared buffer can be 
> subsequently modified by a different thread than the one who made the initial 
> call. Furthermore, two or more different threads can access the same shared 
> buffer at the same time, and modify it, resulting in undefined run-time 
> behavior.
> The cure for this defect has two parts:
> 1. the member functions in question must truly return a copy by avoiding a 
> call to the copy constructor, and using a constructor which creates a deep 
> copy of the std::string.
> 2. access to these member functions must be serialized, in order to guarantee 
> atomicity
> of the creation of the std::string being returned by value.
> Patch for 4.2.1 to follow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (STDCXX-1057) attempting to create a std::string of size 65535 or greater fails with Perennial CPPVS V8.1

2012-02-07 Thread Travis Vitek (Issue Comment Edited) (JIRA) 

[ 
https://issues.apache.org/jira/browse/STDCXX-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202609#comment-13202609
 ] 

Travis Vitek edited comment on STDCXX-1057 at 2/8/12 12:48 AM:
---

The question here is not what value should {{string::max_size()}} or 
{{allocator::max_size()}} return. The question is should the 
{{std::basic_string}} constructors use {{allocator::max_size()}} at all, or 
should they just try to make the allocation request and allow the exception to 
propagate out to the caller?

I believe that Martin is suggesting the constructors should consult 
{{allocator::max_size()}} before making the allocation, and the Perennial 
testcase seems to think that this behavior is forbidden. I read through all of 
21.3.1 and didn't see anything that indicates there is a requirement either 
way. There are requirements relating to this for functions that grow the 
string, but I don't see anything for the string constructors. So, as Martin 
suggests, this is _unspecified behavior_, and as such, the actual behavior is 
_implementation defined_.

  was (Author: vitek):
The question here is not what value should {{string::max_size()}} or 
{{allocator::max_size()}} return. The question is should the 
{{std::basic_string}} constructors use {{basic_string::max_size()}} or 
{{allocator::max_size()}} at all, or should they just try to make the 
allocation request and allow the exception to propagate out to the caller?

I believe that Martin is suggesting the constructors should consult 
{{basic_string::max_size()}} before making the allocation, and the Perennial 
testcase seems to think that this behavior is forbidden. I read through all of 
21.3.1 and didn't see anything that indicates there is a requirement either 
way. There are requirements relating to this for functions that grow the 
string, but I don't see anything for the string constructors. So, as Martin 
suggests, this is _unspecified behavior_, and as such, the actual behavior is 
_implementation defined_.

That said, I did find 
[LWG#83|http://www.open-std.org/Jtc1/sc22/wg21/docs/lwg-defects.html#83], which 
indicates the addition of the following paragraph to the requirements of 
{{std::basic_string}}

{quote}
For any string operation, if as a result of the operation, size() would exceed 
max_size() then the operation throws length_error.
{quote}

A quick check of the C++11 standard shows that as [string.require] p1.
  
> attempting to create a std::string of size 65535 or greater fails with 
> Perennial CPPVS V8.1
> ---
>
> Key: STDCXX-1057
> URL: https://issues.apache.org/jira/browse/STDCXX-1057
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 21. Strings
>Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
> Environment: Solaris 10 and 11, RedHat Linux, OpenSuSE Linux
> SUN C++ Compilers 12.1, 12.2, 12.3
> Defect is independent of compiler and platform
>Reporter: Stefan Teleman
>  Labels: conformance, features, standards, test
> Fix For: 4.2.x, 4.3.x, 5.0.0
>
> Attachments: stdcxx-1057.patch, test.cc
>
>
> in member function:
> size_type basic_string<_CharT, _Traits, _Allocator>::max_size();
> the maximum size of a basic_string is restricted to less than 65535 bytes.
> The Standard is ambiguous as to what the max_size() of a std::string should
> actually be (see LWG Core Issue 197). However, less than 65535 bytes for
> the max_size of a std::string is rather small. GNU libstdc++ and stlport4
> set std::string::max_size to (SIZE_MAX / 4) (i.e. 1GB). Solaris sets it
> to SIZE_MAX.
> Perennial CPPVS explicitly tests for the creation of a std::string of size
> greater than 65535. In the current stdcxx implementation, this test fails.
> The max_size of a std::string should be significantly greater than 65535 
> bytes.
> Test to reproduce the defect:
> {code:title=test.cc|borderStyle=solid}
> #include 
> #include 
> const size_t maxlen = 65536U;
> char array[maxlen];
> struct test_traits : public std::char_traits
> { };
> template
> struct test_alloc : public std::allocator
> {
> typedef typename std::allocator::size_type size_type;
> template
> struct rebind
> {
> typedef test_alloc other;
> };
> test_alloc() throw() { }
> test_alloc(const test_alloc& rhs) throw() { }
> template
> test_alloc(const test_alloc& y) throw() { }
> ~test_alloc() throw() { }
> size_type max_size() const throw() { return maxlen; }
> };
> int main()
> {
> typedef
> std::basic_string > test_string;
> int ret = 0;
> size_t i, j;
> for (i = 0; i < maxlen; i++)
> array[i] = '*';
> array[maxlen - 1] = '\0';
> for (i = 0; i < maxl

[jira] [Updated] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

2012-02-07 Thread Stefan Teleman (Updated) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Teleman updated STDCXX-1056:
---

Attachment: runtests-linux32-all.out

Full build of test harness on OpenSuSE 11.3 with GCC 4.3.0 (32-bit). The first 
runtest.out is missing two test programs (which didn't compile), now fixed.

> std::moneypunct and std::numpunct implementations are not thread-safe
> -
>
> Key: STDCXX-1056
> URL: https://issues.apache.org/jira/browse/STDCXX-1056
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 22. Localization
>Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
> Environment: Solaris 10 and 11, RedHat and OpenSuSE Linux, Sun C++ 
> Compilers 12.1, 12.2, 12.3
> Issue is independent of platform and/or compiler.
>Reporter: Stefan Teleman
>  Labels: thread-safety
> Fix For: 4.2.x, 4.3.x, 5.0.0
>
> Attachments: 22.locale.numpunct.mt.out, runtests-linux32-all.out, 
> runtests.out, stdcxx-1056.patch
>
>
> several member functions in std::moneypunct<> and std::numpunct<> return
> a std::string by value (as required by the Standard). The implication of 
> return-by-value
> being that the caller "owns" the returned object.
> In the stdcxx implementation, the std::basic_string copy constructor uses a 
> shared
> underlying buffer implementation. This shared buffer creates the first 
> problem for
> these classes: although the std::string object returned by value *appears* to 
> be owned
> by the caller, it is, in fact, not.
> In a mult-threaded environment, this underlying shared buffer can be 
> subsequently modified by a different thread than the one who made the initial 
> call. Furthermore, two or more different threads can access the same shared 
> buffer at the same time, and modify it, resulting in undefined run-time 
> behavior.
> The cure for this defect has two parts:
> 1. the member functions in question must truly return a copy by avoiding a 
> call to the copy constructor, and using a constructor which creates a deep 
> copy of the std::string.
> 2. access to these member functions must be serialized, in order to guarantee 
> atomicity
> of the creation of the std::string being returned by value.
> Patch for 4.2.1 to follow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

2012-02-07 Thread Stefan Teleman (Issue Comment Edited) (JIRA) 

[ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202730#comment-13202730
 ] 

Stefan Teleman edited comment on STDCXX-1056 at 2/8/12 12:25 AM:
-

I had to resurrect all my linux patches, and because I hadn't worked on the 
Linux stdcxx for a while I had forgotten a bunch of things:

1. makefile.in:
{noformat}
TOPDIR = /src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe
BUILDDIR   = /src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build
CONFIG = $(TOPDIR)/etc/config/gcc.config
CONFIG_H   = /usr/bin/g++ -m32 -g -O2 -fno-strict-aliasing -frtti 
-fkeep-inline-functions -D_REENTRANT -D_RWSTD_REENTRANT
BUILDTYPE  = 8d
BUILDMODE  = shared,pthreads
CXX= /usr/bin/g++ -m32 -g -O2 -fno-strict-aliasing -frtti 
-fkeep-inline-functions -D_REENTRANT -D_RWSTD_REENTRANT 
-D_RWSTD_NO_EXT_OPERATOR_NEW -D_RWSTD_NO_REPLACEABLE_NEW_DELETE
CXXFLAGS   = -pedantic -nostdinc++
PRELINKFLAGS =
PICFLAGS   = -fPIC
CPPFLAGS   = 
-I/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/include/ansi 
-I/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/include/tr1 
-I/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/include 
-nostdinc++ -pthread
WARNFLAGS  = -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings 
-Wno-long-long -Wcast-align
DEPENDFLAGS = -M
DEPENDFLAGS.cpp =
DEPENDFLAGS.S =
AS_EXT = .S
LD = /usr/bin/g++ -m32 -g -O2 -fno-strict-aliasing -frtti 
-fkeep-inline-functions -D_REENTRANT -D_RWSTD_REENTRANT -nodefaultlibs 
--allow-shlib-undefined
LDFLAGS= -lc -lm -lpthread -lgcc_s
LDLIBS = /usr/lib64/gcc/x86_64-suse-linux/4.5/32/libgcc_eh.a 
/usr/lib64/gcc/x86_64-suse-linux/4.5/32/libsupc++.a
LDSOFLAGS  = -shared
MAPFLAGS   =
RPATH  = -Wl,-R
RUNFLAGS   = -t 300
DEPENDDIR  = .depend
PHDIR  =
PHWARNFLAGS =
LIBSUFFIX  = .so
LIBBASE= std$(BUILDTYPE)
LIBVER = 4.2.1
LIBNAME= lib$(LIBBASE)$(LIBSUFFIX)
AR = ar
ARFLAGS= rv
CCVER  = 4.5
SHARED =
CATFILE=
OMIT_EXM_SRCS =
OMIT_TST_SRCS =
BUILDTAG   =
PLATFORM   = linux-2.6.34.10-0.4-desktop-x86_64
DEFAULT_SHROBJ =
WITH_CADVISE =
CADVISEFLAGS =
WITH_PURIFY =
PURIFYFLAGS =
CXX_REPOSITORY =
{noformat}

Make sure libstd8d.so.4.2.1 does *NOT* link with libstdc++.so. It needs to 
statically link with libsupc++.a and libgcc_eh.a.


  was (Author: steleman):
I had to resurrect all my linux patches, and because I hadn't worked on the 
Linux stdcxx for a while I had forgotten a bunch of things:

1. makefile.in:
{noformat}
TOPDIR = /src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe
BUILDDIR   = /src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build
CONFIG = $(TOPDIR)/etc/config/gcc.config
CONFIG_H   = /usr/bin/g++ -m32 -g -O2 -fno-strict-aliasing -frtti 
-fkeep-inline-functions -D_REENTRANT -D_RWSTD_REENTRANT
BUILDTYPE  = 8d
BUILDMODE  = shared,pthreads
CXX= /usr/bin/g++ -m32 -g -O2 -fno-strict-aliasing -frtti 
-fkeep-inline-functions -D_REENTRANT -D_RWSTD_REENTRANT 
-D_RWSTD_NO_EXT_OPERATOR_NEW -D_RWSTD_NO_OPERATOR_NEW_ARRAY 
-D_RWSTD_NO_REPLACEABLE_NEW_DELETE
CXXFLAGS   = -pedantic -nostdinc++
PRELINKFLAGS =
PICFLAGS   = -fPIC
CPPFLAGS   = 
-I/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/include/ansi 
-I/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/include/tr1 
-I/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/include 
-nostdinc++ -pthread
WARNFLAGS  = -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings 
-Wno-long-long -Wcast-align
DEPENDFLAGS = -M
DEPENDFLAGS.cpp =
DEPENDFLAGS.S =
AS_EXT = .S
LD = /usr/bin/g++ -m32 -g -O2 -fno-strict-aliasing -frtti 
-fkeep-inline-functions -D_REENTRANT -D_RWSTD_REENTRANT -nodefaultlibs 
--allow-shlib-undefined
LDFLAGS= -lc -lm -lpthread -lgcc_s
LDLIBS = /usr/lib64/gcc/x86_64-suse-linux/4.5/32/libgcc_eh.a 
/usr/lib64/gcc/x86_64-suse-linux/4.5/32/libsupc++.a
LDSOFLAGS  = -shared
MAPFLAGS   =
RPATH  = -Wl,-R
RUNFLAGS   = -t 300
DEPENDDIR  = .depend
PHDIR  =
PHWARNFLAGS =
LIBSUFFIX  = .so
LIBBASE= std$(BUILDTYPE)
LIBVER = 4.2.1
LIBNAME= lib$(LIBBASE)$(LIBSUFFIX)
AR = ar
ARFLAGS= rv
CCVER  = 4.5
SHARED =
CATFILE=
OMIT_EXM_SRCS =
OMIT_TST_SRCS =
BUILDTAG   =
PLATFORM   = linux-2.6.34.10-0.4-desktop-x86_64
DEFAULT_SHROBJ =
WITH_CADVISE =
CADVISEFLAGS =
WITH_PURIFY =
PURIFYFLAGS =
CXX_REPOSITORY =
{noformat}

Make sure libstd8d.so.4.2.1 does *NOT* link with libstdc++.so. It needs to 
statically link with libsupc++.a and libgcc_eh.a.

  
> std::moneypunct and std::numpunct implementations are not thread-safe
> -
>
> Key: STDCXX-1056
> URL: https://issues.apache.org/jira/browse/STDCXX-1056
>

[jira] [Issue Comment Edited] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

2012-02-07 Thread Stefan Teleman (Issue Comment Edited) (JIRA) 

[ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202730#comment-13202730
 ] 

Stefan Teleman edited comment on STDCXX-1056 at 2/7/12 11:31 PM:
-

I had to resurrect all my linux patches, and because I hadn't worked on the 
Linux stdcxx for a while I had forgotten a bunch of things:

1. makefile.in:
{noformat}
TOPDIR = /src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe
BUILDDIR   = /src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build
CONFIG = $(TOPDIR)/etc/config/gcc.config
CONFIG_H   = /usr/bin/g++ -m32 -g -O2 -fno-strict-aliasing -frtti 
-fkeep-inline-functions -D_REENTRANT -D_RWSTD_REENTRANT
BUILDTYPE  = 8d
BUILDMODE  = shared,pthreads
CXX= /usr/bin/g++ -m32 -g -O2 -fno-strict-aliasing -frtti 
-fkeep-inline-functions -D_REENTRANT -D_RWSTD_REENTRANT 
-D_RWSTD_NO_EXT_OPERATOR_NEW -D_RWSTD_NO_OPERATOR_NEW_ARRAY 
-D_RWSTD_NO_REPLACEABLE_NEW_DELETE
CXXFLAGS   = -pedantic -nostdinc++
PRELINKFLAGS =
PICFLAGS   = -fPIC
CPPFLAGS   = 
-I/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/include/ansi 
-I/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/include/tr1 
-I/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/include 
-nostdinc++ -pthread
WARNFLAGS  = -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings 
-Wno-long-long -Wcast-align
DEPENDFLAGS = -M
DEPENDFLAGS.cpp =
DEPENDFLAGS.S =
AS_EXT = .S
LD = /usr/bin/g++ -m32 -g -O2 -fno-strict-aliasing -frtti 
-fkeep-inline-functions -D_REENTRANT -D_RWSTD_REENTRANT -nodefaultlibs 
--allow-shlib-undefined
LDFLAGS= -lc -lm -lpthread -lgcc_s
LDLIBS = /usr/lib64/gcc/x86_64-suse-linux/4.5/32/libgcc_eh.a 
/usr/lib64/gcc/x86_64-suse-linux/4.5/32/libsupc++.a
LDSOFLAGS  = -shared
MAPFLAGS   =
RPATH  = -Wl,-R
RUNFLAGS   = -t 300
DEPENDDIR  = .depend
PHDIR  =
PHWARNFLAGS =
LIBSUFFIX  = .so
LIBBASE= std$(BUILDTYPE)
LIBVER = 4.2.1
LIBNAME= lib$(LIBBASE)$(LIBSUFFIX)
AR = ar
ARFLAGS= rv
CCVER  = 4.5
SHARED =
CATFILE=
OMIT_EXM_SRCS =
OMIT_TST_SRCS =
BUILDTAG   =
PLATFORM   = linux-2.6.34.10-0.4-desktop-x86_64
DEFAULT_SHROBJ =
WITH_CADVISE =
CADVISEFLAGS =
WITH_PURIFY =
PURIFYFLAGS =
CXX_REPOSITORY =
{noformat}

Make sure libstd8d.so.4.2.1 does *NOT* link with libstdc++.so. It needs to 
statically link with libsupc++.a and libgcc_eh.a.


  was (Author: steleman):
I had to resurrect all my linux patches, and because I hadn't worked on the 
Linux stdcxx for a while I had forgotten a bunch of things:

1. makefile.in:
{noformat}
TOPDIR = /src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe
BUILDDIR   = /src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build
CONFIG = $(TOPDIR)/etc/config/gcc.config
CONFIG_H   = /usr/bin/g++ -m32 -g -O2 -fno-strict-aliasing -frtti 
-fkeep-inline-functions -D_REENTRANT -D_RWSTD_REENTRANT
BUILDTYPE  = 8d
BUILDMODE  = shared,pthreads
CXX= /usr/bin/g++ -m32 -g -O2 -fno-strict-aliasing -frtti 
-fkeep-inline-functions -D_REENTRANT -D_RWSTD_REENTRANT 
-D_RWSTD_NO_EXT_OPERATOR_NEW -D_RWSTD_NO_OPERATOR_NEW_ARRAY 
-D_RWSTD_NO_REPLACEABLE_NEW_DELETE
CXXFLAGS   = -pedantic -nostdinc++
PRELINKFLAGS =
PICFLAGS   = -fPIC
CPPFLAGS   = 
-I/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/include/ansi 
-I/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/include/tr1 
-I/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/include 
-nostdinc++ -pthread
WARNFLAGS  = -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings 
-Wno-long-long -Wcast-align
DEPENDFLAGS = -M
DEPENDFLAGS.cpp =
DEPENDFLAGS.S =
AS_EXT = .S
LD = /usr/bin/g++ -m32 -g -O2 -fno-strict-aliasing -frtti 
-fkeep-inline-functions -D_REENTRANT -D_RWSTD_REENTRANT -nodefaultlibs 
--allow-shlib-undefined
LDFLAGS= -lc -lm -lpthread
LDLIBS = /usr/lib64/gcc/x86_64-suse-linux/4.5/32/libgcc_eh.a 
/usr/lib64/gcc/x86_64-suse-linux/4.5/32/libsupc++.a
LDSOFLAGS  = -shared
MAPFLAGS   =
RPATH  = -Wl,-R
RUNFLAGS   = -t 300
DEPENDDIR  = .depend
PHDIR  =
PHWARNFLAGS =
LIBSUFFIX  = .so
LIBBASE= std$(BUILDTYPE)
LIBVER = 4.2.1
LIBNAME= lib$(LIBBASE)$(LIBSUFFIX)
AR = ar
ARFLAGS= rv
CCVER  = 4.5
SHARED =
CATFILE=
OMIT_EXM_SRCS =
OMIT_TST_SRCS =
BUILDTAG   =
PLATFORM   = linux-2.6.34.10-0.4-desktop-x86_64
DEFAULT_SHROBJ =
WITH_CADVISE =
CADVISEFLAGS =
WITH_PURIFY =
PURIFYFLAGS =
CXX_REPOSITORY =
{noformat}

Make sure libstd8d.so.4.2.1 does *NOT* link with libstdc++.so. It needs to 
statically link with libsupc++.a and libgcc_eh.a.

  
> std::moneypunct and std::numpunct implementations are not thread-safe
> -
>
> Key: STDCXX-1056
> URL: https://issues.apache.org/j

[jira] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

2012-02-07 Thread Stefan Teleman (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202809#comment-13202809
 ] 

Stefan Teleman commented on STDCXX-1056:


Attached output from running all the tests (32-bit) on OpenSuSE Linux 11.3 with 
GCC 4.5.0.

> std::moneypunct and std::numpunct implementations are not thread-safe
> -
>
> Key: STDCXX-1056
> URL: https://issues.apache.org/jira/browse/STDCXX-1056
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 22. Localization
>Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
> Environment: Solaris 10 and 11, RedHat and OpenSuSE Linux, Sun C++ 
> Compilers 12.1, 12.2, 12.3
> Issue is independent of platform and/or compiler.
>Reporter: Stefan Teleman
>  Labels: thread-safety
> Fix For: 4.2.x, 4.3.x, 5.0.0
>
> Attachments: 22.locale.numpunct.mt.out, runtests.out, 
> stdcxx-1056.patch
>
>
> several member functions in std::moneypunct<> and std::numpunct<> return
> a std::string by value (as required by the Standard). The implication of 
> return-by-value
> being that the caller "owns" the returned object.
> In the stdcxx implementation, the std::basic_string copy constructor uses a 
> shared
> underlying buffer implementation. This shared buffer creates the first 
> problem for
> these classes: although the std::string object returned by value *appears* to 
> be owned
> by the caller, it is, in fact, not.
> In a mult-threaded environment, this underlying shared buffer can be 
> subsequently modified by a different thread than the one who made the initial 
> call. Furthermore, two or more different threads can access the same shared 
> buffer at the same time, and modify it, resulting in undefined run-time 
> behavior.
> The cure for this defect has two parts:
> 1. the member functions in question must truly return a copy by avoiding a 
> call to the copy constructor, and using a constructor which creates a deep 
> copy of the std::string.
> 2. access to these member functions must be serialized, in order to guarantee 
> atomicity
> of the creation of the std::string being returned by value.
> Patch for 4.2.1 to follow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

2012-02-07 Thread Stefan Teleman (Updated) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Teleman updated STDCXX-1056:
---

Attachment: runtests.out

Output capture from running all the tests in build/tests (32-bit). Environment:

- Linux darthvader 2.6.34.10-0.4-desktop #1 SMP PREEMPT 2011-10-19 22:16:41 
+0200 x86_64 x86_64 x86_64 GNU/Linux

- g++ (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292]


> std::moneypunct and std::numpunct implementations are not thread-safe
> -
>
> Key: STDCXX-1056
> URL: https://issues.apache.org/jira/browse/STDCXX-1056
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 22. Localization
>Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
> Environment: Solaris 10 and 11, RedHat and OpenSuSE Linux, Sun C++ 
> Compilers 12.1, 12.2, 12.3
> Issue is independent of platform and/or compiler.
>Reporter: Stefan Teleman
>  Labels: thread-safety
> Fix For: 4.2.x, 4.3.x, 5.0.0
>
> Attachments: 22.locale.numpunct.mt.out, runtests.out, 
> stdcxx-1056.patch
>
>
> several member functions in std::moneypunct<> and std::numpunct<> return
> a std::string by value (as required by the Standard). The implication of 
> return-by-value
> being that the caller "owns" the returned object.
> In the stdcxx implementation, the std::basic_string copy constructor uses a 
> shared
> underlying buffer implementation. This shared buffer creates the first 
> problem for
> these classes: although the std::string object returned by value *appears* to 
> be owned
> by the caller, it is, in fact, not.
> In a mult-threaded environment, this underlying shared buffer can be 
> subsequently modified by a different thread than the one who made the initial 
> call. Furthermore, two or more different threads can access the same shared 
> buffer at the same time, and modify it, resulting in undefined run-time 
> behavior.
> The cure for this defect has two parts:
> 1. the member functions in question must truly return a copy by avoiding a 
> call to the copy constructor, and using a constructor which creates a deep 
> copy of the std::string.
> 2. access to these member functions must be serialized, in order to guarantee 
> atomicity
> of the creation of the std::string being returned by value.
> Patch for 4.2.1 to follow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (STDCXX-1057) attempting to create a std::string of size 65535 or greater fails with Perennial CPPVS V8.1

2012-02-07 Thread Stefan Teleman (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/STDCXX-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202745#comment-13202745
 ] 

Stefan Teleman commented on STDCXX-1057:


Yes, GNU libstdc++ sets it to (SIZE_MAX / 4) which means 1GB > 65K.

Stlport sets it to SIZE_MAX. SunPro C++ sets it to SIZE_MAX both in libCstd.so 
and libstdcxx4.so.



> attempting to create a std::string of size 65535 or greater fails with 
> Perennial CPPVS V8.1
> ---
>
> Key: STDCXX-1057
> URL: https://issues.apache.org/jira/browse/STDCXX-1057
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 21. Strings
>Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
> Environment: Solaris 10 and 11, RedHat Linux, OpenSuSE Linux
> SUN C++ Compilers 12.1, 12.2, 12.3
> Defect is independent of compiler and platform
>Reporter: Stefan Teleman
>  Labels: conformance, features, standards, test
> Fix For: 4.2.x, 4.3.x, 5.0.0
>
> Attachments: stdcxx-1057.patch, test.cc
>
>
> in member function:
> size_type basic_string<_CharT, _Traits, _Allocator>::max_size();
> the maximum size of a basic_string is restricted to less than 65535 bytes.
> The Standard is ambiguous as to what the max_size() of a std::string should
> actually be (see LWG Core Issue 197). However, less than 65535 bytes for
> the max_size of a std::string is rather small. GNU libstdc++ and stlport4
> set std::string::max_size to (SIZE_MAX / 4) (i.e. 1GB). Solaris sets it
> to SIZE_MAX.
> Perennial CPPVS explicitly tests for the creation of a std::string of size
> greater than 65535. In the current stdcxx implementation, this test fails.
> The max_size of a std::string should be significantly greater than 65535 
> bytes.
> Test to reproduce the defect:
> {code:title=test.cc|borderStyle=solid}
> #include 
> #include 
> const size_t maxlen = 65536U;
> char array[maxlen];
> struct test_traits : public std::char_traits
> { };
> template
> struct test_alloc : public std::allocator
> {
> typedef typename std::allocator::size_type size_type;
> template
> struct rebind
> {
> typedef test_alloc other;
> };
> test_alloc() throw() { }
> test_alloc(const test_alloc& rhs) throw() { }
> template
> test_alloc(const test_alloc& y) throw() { }
> ~test_alloc() throw() { }
> size_type max_size() const throw() { return maxlen; }
> };
> int main()
> {
> typedef
> std::basic_string > test_string;
> int ret = 0;
> size_t i, j;
> for (i = 0; i < maxlen; i++)
> array[i] = '*';
> array[maxlen - 1] = '\0';
> for (i = 0; i < maxlen - 1; i+= 8)
> {
> array[i] = '\0';
> test_string s(array);
> j = s.size();
> array[i] = '-';
> if (i != j)
> {
> std::cerr << "i = " << i << " j = " << j << " expected i == j"
>   << std::endl;
> ret = 1;
> break;
> }
> }
> return ret;
> }
> {code}
> 1. Output from GCC 4.5.0:
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:16:34][2162]>> ./test-gcc
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:16:48][2163]>> echo $status
> 0
> {noformat}
> 2. Output from Sun C++ 12.2 with stlport:
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:16:50][2164]>> ./test-ss122-stlport 
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:16:58][2165]>> echo $status
> 0
> {noformat}
> 3. Output from Sun C++ 12.2 with our patched stdcxx:
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:17:00][2166]>> ./test-ss122-stdcxx 
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:17:06][2167]>> echo $status
> 0
> {noformat}
> 4. Output from Pathscale 4.0.12.1 (which did not patch stdcxx):
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:17:08][2168]>> ./test-pathscale 
> Terminating due to uncaught exception 0x614240 of type std::length_error
> Abort (core dumped)
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:17:13][2169]>> echo $status
> 134
> {noformat}
> Patch for 4.2.1 to follow shortly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:

[jira] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

2012-02-07 Thread Stefan Teleman (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202730#comment-13202730
 ] 

Stefan Teleman commented on STDCXX-1056:


I had to resurrect all my linux patches, and because I hadn't worked on the 
Linux stdcxx for a while I had forgotten a bunch of things:

1. makefile.in:
{noformat}
TOPDIR = /src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe
BUILDDIR   = /src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build
CONFIG = $(TOPDIR)/etc/config/gcc.config
CONFIG_H   = /usr/bin/g++ -m32 -g -O2 -fno-strict-aliasing -frtti 
-fkeep-inline-functions -D_REENTRANT -D_RWSTD_REENTRANT
BUILDTYPE  = 8d
BUILDMODE  = shared,pthreads
CXX= /usr/bin/g++ -m32 -g -O2 -fno-strict-aliasing -frtti 
-fkeep-inline-functions -D_REENTRANT -D_RWSTD_REENTRANT 
-D_RWSTD_NO_EXT_OPERATOR_NEW -D_RWSTD_NO_OPERATOR_NEW_ARRAY 
-D_RWSTD_NO_REPLACEABLE_NEW_DELETE
CXXFLAGS   = -pedantic -nostdinc++
PRELINKFLAGS =
PICFLAGS   = -fPIC
CPPFLAGS   = 
-I/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/include/ansi 
-I/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/include/tr1 
-I/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/include 
-nostdinc++ -pthread
WARNFLAGS  = -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings 
-Wno-long-long -Wcast-align
DEPENDFLAGS = -M
DEPENDFLAGS.cpp =
DEPENDFLAGS.S =
AS_EXT = .S
LD = /usr/bin/g++ -m32 -g -O2 -fno-strict-aliasing -frtti 
-fkeep-inline-functions -D_REENTRANT -D_RWSTD_REENTRANT -nodefaultlibs 
--allow-shlib-undefined
LDFLAGS= -lc -lm -lpthread
LDLIBS = /usr/lib64/gcc/x86_64-suse-linux/4.5/32/libgcc_eh.a 
/usr/lib64/gcc/x86_64-suse-linux/4.5/32/libsupc++.a
LDSOFLAGS  = -shared
MAPFLAGS   =
RPATH  = -Wl,-R
RUNFLAGS   = -t 300
DEPENDDIR  = .depend
PHDIR  =
PHWARNFLAGS =
LIBSUFFIX  = .so
LIBBASE= std$(BUILDTYPE)
LIBVER = 4.2.1
LIBNAME= lib$(LIBBASE)$(LIBSUFFIX)
AR = ar
ARFLAGS= rv
CCVER  = 4.5
SHARED =
CATFILE=
OMIT_EXM_SRCS =
OMIT_TST_SRCS =
BUILDTAG   =
PLATFORM   = linux-2.6.34.10-0.4-desktop-x86_64
DEFAULT_SHROBJ =
WITH_CADVISE =
CADVISEFLAGS =
WITH_PURIFY =
PURIFYFLAGS =
CXX_REPOSITORY =
{noformat}

Make sure libstd8d.so.4.2.1 does *NOT* link with libstdc++.so. It needs to 
statically link with libsupc++.a and libgcc_eh.a.


> std::moneypunct and std::numpunct implementations are not thread-safe
> -
>
> Key: STDCXX-1056
> URL: https://issues.apache.org/jira/browse/STDCXX-1056
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 22. Localization
>Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
> Environment: Solaris 10 and 11, RedHat and OpenSuSE Linux, Sun C++ 
> Compilers 12.1, 12.2, 12.3
> Issue is independent of platform and/or compiler.
>Reporter: Stefan Teleman
>  Labels: thread-safety
> Fix For: 4.2.x, 4.3.x, 5.0.0
>
> Attachments: 22.locale.numpunct.mt.out, stdcxx-1056.patch
>
>
> several member functions in std::moneypunct<> and std::numpunct<> return
> a std::string by value (as required by the Standard). The implication of 
> return-by-value
> being that the caller "owns" the returned object.
> In the stdcxx implementation, the std::basic_string copy constructor uses a 
> shared
> underlying buffer implementation. This shared buffer creates the first 
> problem for
> these classes: although the std::string object returned by value *appears* to 
> be owned
> by the caller, it is, in fact, not.
> In a mult-threaded environment, this underlying shared buffer can be 
> subsequently modified by a different thread than the one who made the initial 
> call. Furthermore, two or more different threads can access the same shared 
> buffer at the same time, and modify it, resulting in undefined run-time 
> behavior.
> The cure for this defect has two parts:
> 1. the member functions in question must truly return a copy by avoiding a 
> call to the copy constructor, and using a constructor which creates a deep 
> copy of the std::string.
> 2. access to these member functions must be serialized, in order to guarantee 
> atomicity
> of the creation of the std::string being returned by value.
> Patch for 4.2.1 to follow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

2012-02-07 Thread Stefan Teleman (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202723#comment-13202723
 ] 

Stefan Teleman commented on STDCXX-1056:


{noformat}
[steleman@darthvader][/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build/tests][02/07/2012
 15:09:44][2249]>> ./22.locale.numpunct.mt --nthreads=4 --nloops=100
# INFO (S1) (10 lines):
# TEXT: 
# COMPILER: gcc 4.5.0, __VERSION__ = "4.5.0 20100604 [gcc-4_5-branch revision 
160292]"
# ENVIRONMENT: pentium running linux-elf (openSUSE 11.3 (x86_64)) with glibc 
2.11
# FILE: 22.locale.numpunct.mt.cpp
# COMPILED: Feb  7 2012, 14:31:03
# COMMENT: thread safety


# CLAUSE: lib.locale.numpunct

# NOTE (S2) (5 lines):
# TEXT: executing "locale -a > /tmp/tmpfile-i3QHMP"
# CLAUSE: lib.locale.numpunct
# FILE: process.cpp
# LINE: 276

# INFO (S1) (3 lines):
# TEXT: testing std::numpunct with 4 threads, 100 iterations each, in 32 
locales { "C" "aa_DJ" "aa_DJ.utf8" "aa_ER" "aa_ER@saaho" "aa_ER.utf8" "aa_ET" 
"aa_ET.utf8" "af_ZA" "af_ZA.utf8" "am_ET" "am_ET.utf8" "an_ES" "an_ES.utf8" 
"ar_AE" "ar_AE.utf8" "ar_BH" "ar_BH.utf8" "ar_DZ" "ar_DZ.utf8" "ar_EG" 
"ar_EG.utf8" "ar_IN" "ar_IN.utf8" "ar_IQ" "ar_IQ.utf8" "ar_JO" "ar_JO.utf8" 
"ar_KW" "ar_KW.utf8" "ar_LB" "ar_LB.utf8" }
# CLAUSE: lib.locale.numpunct

# INFO (S1) (3 lines):
# TEXT: exercising std::numpunct
# CLAUSE: lib.locale.numpunct

# INFO (S1) (4 lines):
# TEXT: requesting a thread pool with 4 threads
# CLAUSE: lib.locale.numpunct
# LINE: 503

# INFO (S1) (4 lines):
# TEXT: creating a thread pool with 4 threads
# CLAUSE: lib.locale.numpunct
# LINE: 548

# INFO (S1) (3 lines):
# TEXT: exercising std::numpunct
# CLAUSE: lib.locale.numpunct

# INFO (S1) (4 lines):
# TEXT: requesting a thread pool with 4 threads
# CLAUSE: lib.locale.numpunct
# LINE: 503

# INFO (S1) (4 lines):
# TEXT: creating a thread pool with 4 threads
# CLAUSE: lib.locale.numpunct
# LINE: 548

# INFO (S1) (3 lines):
# TEXT: exercising both std::numpunct and std::numpunct
# CLAUSE: lib.locale.numpunct

# INFO (S1) (4 lines):
# TEXT: requesting a thread pool with 4 threads
# CLAUSE: lib.locale.numpunct
# LINE: 503

# INFO (S1) (4 lines):
# TEXT: creating a thread pool with 4 threads
# CLAUSE: lib.locale.numpunct
# LINE: 548

# +---+--+--+--+
# | DIAGNOSTIC|  ACTIVE  |   TOTAL  | INACTIVE |
# +---+--+--+--+
# | (S1) INFO |   11 |   11 |   0% |
# | (S2) NOTE |1 |1 |   0% |
# | (S8) ERROR|0 |3 | 100% |
# | (S9) FATAL|0 |1 | 100% |
# +---+--+--+--+
[steleman@darthvader][/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build/tests][02/07/2012
 15:09:54][2250]>> 
{noformat}



> std::moneypunct and std::numpunct implementations are not thread-safe
> -
>
> Key: STDCXX-1056
> URL: https://issues.apache.org/jira/browse/STDCXX-1056
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 22. Localization
>Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
> Environment: Solaris 10 and 11, RedHat and OpenSuSE Linux, Sun C++ 
> Compilers 12.1, 12.2, 12.3
> Issue is independent of platform and/or compiler.
>Reporter: Stefan Teleman
>  Labels: thread-safety
> Fix For: 4.2.x, 4.3.x, 5.0.0
>
> Attachments: 22.locale.numpunct.mt.out, stdcxx-1056.patch
>
>
> several member functions in std::moneypunct<> and std::numpunct<> return
> a std::string by value (as required by the Standard). The implication of 
> return-by-value
> being that the caller "owns" the returned object.
> In the stdcxx implementation, the std::basic_string copy constructor uses a 
> shared
> underlying buffer implementation. This shared buffer creates the first 
> problem for
> these classes: although the std::string object returned by value *appears* to 
> be owned
> by the caller, it is, in fact, not.
> In a mult-threaded environment, this underlying shared buffer can be 
> subsequently modified by a different thread than the one who made the initial 
> call. Furthermore, two or more different threads can access the same shared 
> buffer at the same time, and modify it, resulting in undefined run-time 
> behavior.
> The cure for this defect has two parts:
> 1. the member functions in question must truly return a copy by avoiding a 
> call to the copy constructor, and using a constructor which creates a deep 
> copy of the std::string.
> 2. access to these member functions must be serialized, in order to guarantee 
> atomicity
> of the

[jira] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

2012-02-07 Thread Stefan Teleman (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202721#comment-13202721
 ] 

Stefan Teleman commented on STDCXX-1056:


{noformat}
[steleman@darthvader][/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build/tests][02/07/2012
 15:06:19][2241]>> ./22.locale.messages.mt --nthreads=4 --nloops=100
# INFO (S1) (10 lines):
# TEXT: 
# COMPILER: gcc 4.5.0, __VERSION__ = "4.5.0 20100604 [gcc-4_5-branch revision 
160292]"
# ENVIRONMENT: pentium running linux-elf (openSUSE 11.3 (x86_64)) with glibc 
2.11
# FILE: 22.locale.messages.mt.cpp
# COMPILED: Feb  7 2012, 14:31:03
# COMMENT: thread safety


# CLAUSE: lib.locale.messages

# NOTE (S2) (5 lines):
# TEXT: executing "gencat rwstdmessages.cat rwstdmessages.msg"
# CLAUSE: lib.locale.messages
# FILE: process.cpp
# LINE: 276

# INFO (S1) (3 lines):
# TEXT: testing std::messages with 4 threads, 100 iterations each
# CLAUSE: lib.locale.messages

# INFO (S1) (3 lines):
# TEXT: exercising std::messages
# CLAUSE: lib.locale.messages

# INFO (S1) (4 lines):
# TEXT: requesting a thread pool with 4 threads
# CLAUSE: lib.locale.messages
# LINE: 503

# INFO (S1) (4 lines):
# TEXT: creating a thread pool with 4 threads
# CLAUSE: lib.locale.messages
# LINE: 548

# INFO (S1) (3 lines):
# TEXT: exercising std::messages
# CLAUSE: lib.locale.messages

# INFO (S1) (4 lines):
# TEXT: requesting a thread pool with 4 threads
# CLAUSE: lib.locale.messages
# LINE: 503

# INFO (S1) (4 lines):
# TEXT: creating a thread pool with 4 threads
# CLAUSE: lib.locale.messages
# LINE: 548

# INFO (S1) (3 lines):
# TEXT: exercising std::messages and std::messages
# CLAUSE: lib.locale.messages

# INFO (S1) (4 lines):
# TEXT: requesting a thread pool with 4 threads
# CLAUSE: lib.locale.messages
# LINE: 503

# INFO (S1) (4 lines):
# TEXT: creating a thread pool with 4 threads
# CLAUSE: lib.locale.messages
# LINE: 548

# +---+--+--+--+
# | DIAGNOSTIC|  ACTIVE  |   TOTAL  | INACTIVE |
# +---+--+--+--+
# | (S1) INFO |   11 |   11 |   0% |
# | (S2) NOTE |1 |1 |   0% |
# | (S8) ERROR|0 |3 | 100% |
# +---+--+--+--+
[steleman@darthvader][/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build/tests][02/07/2012
 15:06:22][2241]>> uname -a
Linux darthvader 2.6.34.10-0.4-desktop #1 SMP PREEMPT 2011-10-19 22:16:41 +0200 
x86_64 x86_64 x86_64 GNU/Linux
[steleman@darthvader][/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build/tests][02/07/2012
 15:06:25][2242]>> ldd 22.locale.messages.mt
linux-gate.so.1 =>  (0xe000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf7705000)

/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build/lib/libstd8d.so
 (0xf75f8000)
libm.so.6 => /lib/libm.so.6 (0xf75ce000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf74dd000)
libc.so.6 => /lib/libc.so.6 (0xf7373000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7355000)
/lib/ld-linux.so.2 (0xf7775000)
[steleman@darthvader][/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build/tests][02/07/2012
 15:07:40][2243]>> ldd ../lib/libstd
libstd8d.so@   libstd8d.so.4.2.1* 
[steleman@darthvader][/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build/tests][02/07/2012
 15:07:40][2243]>> ldd ../lib/libstd8d.so.4.2.1 
linux-gate.so.1 =>  (0xe000)
libc.so.6 => /lib/libc.so.6 (0xf756)
libm.so.6 => /lib/libm.so.6 (0xf7536000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf751b000)
/lib/ld-linux.so.2 (0xf77d9000)
[steleman@darthvader][/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build/tests][02/07/2012
 15:08:06][2244]>>
{noformat}


> std::moneypunct and std::numpunct implementations are not thread-safe
> -
>
> Key: STDCXX-1056
> URL: https://issues.apache.org/jira/browse/STDCXX-1056
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 22. Localization
>Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
> Environment: Solaris 10 and 11, RedHat and OpenSuSE Linux, Sun C++ 
> Compilers 12.1, 12.2, 12.3
> Issue is independent of platform and/or compiler.
>Reporter: Stefan Teleman
>  Labels: thread-safety
> Fix For: 4.2.x, 4.3.x, 5.0.0
>
> Attachments: 22.locale.numpunct.mt.out, stdcxx-1056.patch
>
>
> several member functions in std::moneypunct<> and std::numpunct<> return
> a std::string by value (as required by the Standard). The imp

[jira] [Commented] (STDCXX-1057) attempting to create a std::string of size 65535 or greater fails with Perennial CPPVS V8.1

2012-02-07 Thread Travis Vitek (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/STDCXX-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202626#comment-13202626
 ] 

Travis Vitek commented on STDCXX-1057:
--

Also, just for information, the GNU implementation sets 
{{basic_string::max_size()}} to something smaller than {{SIZE_MAX}} (see 
[basic_string.tcc|http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/bits/basic_string.tcc?revision=179961&view=markup]:53).
 So if the testcase used a different magic number, you'd see the same behavior 
as stdcxx.



> attempting to create a std::string of size 65535 or greater fails with 
> Perennial CPPVS V8.1
> ---
>
> Key: STDCXX-1057
> URL: https://issues.apache.org/jira/browse/STDCXX-1057
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 21. Strings
>Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
> Environment: Solaris 10 and 11, RedHat Linux, OpenSuSE Linux
> SUN C++ Compilers 12.1, 12.2, 12.3
> Defect is independent of compiler and platform
>Reporter: Stefan Teleman
>  Labels: conformance, features, standards, test
> Fix For: 4.2.x, 4.3.x, 5.0.0
>
> Attachments: stdcxx-1057.patch, test.cc
>
>
> in member function:
> size_type basic_string<_CharT, _Traits, _Allocator>::max_size();
> the maximum size of a basic_string is restricted to less than 65535 bytes.
> The Standard is ambiguous as to what the max_size() of a std::string should
> actually be (see LWG Core Issue 197). However, less than 65535 bytes for
> the max_size of a std::string is rather small. GNU libstdc++ and stlport4
> set std::string::max_size to (SIZE_MAX / 4) (i.e. 1GB). Solaris sets it
> to SIZE_MAX.
> Perennial CPPVS explicitly tests for the creation of a std::string of size
> greater than 65535. In the current stdcxx implementation, this test fails.
> The max_size of a std::string should be significantly greater than 65535 
> bytes.
> Test to reproduce the defect:
> {code:title=test.cc|borderStyle=solid}
> #include 
> #include 
> const size_t maxlen = 65536U;
> char array[maxlen];
> struct test_traits : public std::char_traits
> { };
> template
> struct test_alloc : public std::allocator
> {
> typedef typename std::allocator::size_type size_type;
> template
> struct rebind
> {
> typedef test_alloc other;
> };
> test_alloc() throw() { }
> test_alloc(const test_alloc& rhs) throw() { }
> template
> test_alloc(const test_alloc& y) throw() { }
> ~test_alloc() throw() { }
> size_type max_size() const throw() { return maxlen; }
> };
> int main()
> {
> typedef
> std::basic_string > test_string;
> int ret = 0;
> size_t i, j;
> for (i = 0; i < maxlen; i++)
> array[i] = '*';
> array[maxlen - 1] = '\0';
> for (i = 0; i < maxlen - 1; i+= 8)
> {
> array[i] = '\0';
> test_string s(array);
> j = s.size();
> array[i] = '-';
> if (i != j)
> {
> std::cerr << "i = " << i << " j = " << j << " expected i == j"
>   << std::endl;
> ret = 1;
> break;
> }
> }
> return ret;
> }
> {code}
> 1. Output from GCC 4.5.0:
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:16:34][2162]>> ./test-gcc
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:16:48][2163]>> echo $status
> 0
> {noformat}
> 2. Output from Sun C++ 12.2 with stlport:
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:16:50][2164]>> ./test-ss122-stlport 
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:16:58][2165]>> echo $status
> 0
> {noformat}
> 3. Output from Sun C++ 12.2 with our patched stdcxx:
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:17:00][2166]>> ./test-ss122-stdcxx 
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:17:06][2167]>> echo $status
> 0
> {noformat}
> 4. Output from Pathscale 4.0.12.1 (which did not patch stdcxx):
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:17:08][2168]>> ./test-pathscale 
> Terminating due to uncaught exception 0x614240 of type std::length_error
> Abort (core dumped)
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:17:13][2169]>> echo $status
> 134
> {noformat}
> Patch for 4.2.1 to follow shortly.

--
This message is automatically generated by JIRA.
If yo

[jira] [Commented] (STDCXX-1057) attempting to create a std::string of size 65535 or greater fails with Perennial CPPVS V8.1

2012-02-07 Thread Martin Sebor (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/STDCXX-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202606#comment-13202606
 ] 

Martin Sebor commented on STDCXX-1057:
--

I don't have access to too many other libraries but, IIRC, from talking to 
other implementers on the C++ committee when the function was discussed, other 
libraries tend to simply hardcode some large constant directly into 
{{basic_string::max_size()}}, making the function not terribly useful. The 
committee discussed a proposal to make the function more useful and chose to do 
nothing. Library Issue 
[197|http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#197] has the 
background. FWIW, I argued for a change that would make it possible (but not 
required) to provide (4) in the issue because that, in my view, would make the 
function the most useful. This is what stdcxx does.

> attempting to create a std::string of size 65535 or greater fails with 
> Perennial CPPVS V8.1
> ---
>
> Key: STDCXX-1057
> URL: https://issues.apache.org/jira/browse/STDCXX-1057
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 21. Strings
>Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
> Environment: Solaris 10 and 11, RedHat Linux, OpenSuSE Linux
> SUN C++ Compilers 12.1, 12.2, 12.3
> Defect is independent of compiler and platform
>Reporter: Stefan Teleman
>  Labels: conformance, features, standards, test
> Fix For: 4.2.x, 4.3.x, 5.0.0
>
> Attachments: stdcxx-1057.patch, test.cc
>
>
> in member function:
> size_type basic_string<_CharT, _Traits, _Allocator>::max_size();
> the maximum size of a basic_string is restricted to less than 65535 bytes.
> The Standard is ambiguous as to what the max_size() of a std::string should
> actually be (see LWG Core Issue 197). However, less than 65535 bytes for
> the max_size of a std::string is rather small. GNU libstdc++ and stlport4
> set std::string::max_size to (SIZE_MAX / 4) (i.e. 1GB). Solaris sets it
> to SIZE_MAX.
> Perennial CPPVS explicitly tests for the creation of a std::string of size
> greater than 65535. In the current stdcxx implementation, this test fails.
> The max_size of a std::string should be significantly greater than 65535 
> bytes.
> Test to reproduce the defect:
> {code:title=test.cc|borderStyle=solid}
> #include 
> #include 
> const size_t maxlen = 65536U;
> char array[maxlen];
> struct test_traits : public std::char_traits
> { };
> template
> struct test_alloc : public std::allocator
> {
> typedef typename std::allocator::size_type size_type;
> template
> struct rebind
> {
> typedef test_alloc other;
> };
> test_alloc() throw() { }
> test_alloc(const test_alloc& rhs) throw() { }
> template
> test_alloc(const test_alloc& y) throw() { }
> ~test_alloc() throw() { }
> size_type max_size() const throw() { return maxlen; }
> };
> int main()
> {
> typedef
> std::basic_string > test_string;
> int ret = 0;
> size_t i, j;
> for (i = 0; i < maxlen; i++)
> array[i] = '*';
> array[maxlen - 1] = '\0';
> for (i = 0; i < maxlen - 1; i+= 8)
> {
> array[i] = '\0';
> test_string s(array);
> j = s.size();
> array[i] = '-';
> if (i != j)
> {
> std::cerr << "i = " << i << " j = " << j << " expected i == j"
>   << std::endl;
> ret = 1;
> break;
> }
> }
> return ret;
> }
> {code}
> 1. Output from GCC 4.5.0:
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:16:34][2162]>> ./test-gcc
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:16:48][2163]>> echo $status
> 0
> {noformat}
> 2. Output from Sun C++ 12.2 with stlport:
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:16:50][2164]>> ./test-ss122-stlport 
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:16:58][2165]>> echo $status
> 0
> {noformat}
> 3. Output from Sun C++ 12.2 with our patched stdcxx:
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:17:00][2166]>> ./test-ss122-stdcxx 
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:17:06][2167]>> echo $status
> 0
> {noformat}
> 4. Output from Pathscale 4.0.12.1 (which did not patch stdcxx):
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:17:08][2168]>> ./test-pathscale 
> T

[jira] [Commented] (STDCXX-1057) attempting to create a std::string of size 65535 or greater fails with Perennial CPPVS V8.1

2012-02-07 Thread Travis Vitek (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/STDCXX-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202609#comment-13202609
 ] 

Travis Vitek commented on STDCXX-1057:
--

The question here is not what value should {{string::max_size()}} or 
{{allocator::max_size()}} return. The question is should the 
{{std::basic_string}} constructors use {{basic_string::max_size()}} or 
{{allocator::max_size()}} at all, or should they just try to make the 
allocation request and allow the exception to propagate out to the caller?

I believe that Martin is suggesting the constructors should consult 
{{basic_string::max_size()}} before making the allocation, and the Perennial 
testcase seems to think that this behavior is forbidden. I read through all of 
21.3.1 and didn't see anything that indicates there is a requirement either 
way. There are requirements relating to this for functions that grow the 
string, but I don't see anything for the string constructors. So, as Martin 
suggests, this is _unspecified behavior_, and as such, the actual behavior is 
_implementation defined_.

That said, I did find 
[LWG#83|http://www.open-std.org/Jtc1/sc22/wg21/docs/lwg-defects.html#83], which 
indicates the addition of the following paragraph to the requirements of 
{{std::basic_string}}

{quote}
For any string operation, if as a result of the operation, size() would exceed 
max_size() then the operation throws length_error.
{quote}

A quick check of the C++11 standard shows that as [string.require] p1.

> attempting to create a std::string of size 65535 or greater fails with 
> Perennial CPPVS V8.1
> ---
>
> Key: STDCXX-1057
> URL: https://issues.apache.org/jira/browse/STDCXX-1057
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 21. Strings
>Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
> Environment: Solaris 10 and 11, RedHat Linux, OpenSuSE Linux
> SUN C++ Compilers 12.1, 12.2, 12.3
> Defect is independent of compiler and platform
>Reporter: Stefan Teleman
>  Labels: conformance, features, standards, test
> Fix For: 4.2.x, 4.3.x, 5.0.0
>
> Attachments: stdcxx-1057.patch, test.cc
>
>
> in member function:
> size_type basic_string<_CharT, _Traits, _Allocator>::max_size();
> the maximum size of a basic_string is restricted to less than 65535 bytes.
> The Standard is ambiguous as to what the max_size() of a std::string should
> actually be (see LWG Core Issue 197). However, less than 65535 bytes for
> the max_size of a std::string is rather small. GNU libstdc++ and stlport4
> set std::string::max_size to (SIZE_MAX / 4) (i.e. 1GB). Solaris sets it
> to SIZE_MAX.
> Perennial CPPVS explicitly tests for the creation of a std::string of size
> greater than 65535. In the current stdcxx implementation, this test fails.
> The max_size of a std::string should be significantly greater than 65535 
> bytes.
> Test to reproduce the defect:
> {code:title=test.cc|borderStyle=solid}
> #include 
> #include 
> const size_t maxlen = 65536U;
> char array[maxlen];
> struct test_traits : public std::char_traits
> { };
> template
> struct test_alloc : public std::allocator
> {
> typedef typename std::allocator::size_type size_type;
> template
> struct rebind
> {
> typedef test_alloc other;
> };
> test_alloc() throw() { }
> test_alloc(const test_alloc& rhs) throw() { }
> template
> test_alloc(const test_alloc& y) throw() { }
> ~test_alloc() throw() { }
> size_type max_size() const throw() { return maxlen; }
> };
> int main()
> {
> typedef
> std::basic_string > test_string;
> int ret = 0;
> size_t i, j;
> for (i = 0; i < maxlen; i++)
> array[i] = '*';
> array[maxlen - 1] = '\0';
> for (i = 0; i < maxlen - 1; i+= 8)
> {
> array[i] = '\0';
> test_string s(array);
> j = s.size();
> array[i] = '-';
> if (i != j)
> {
> std::cerr << "i = " << i << " j = " << j << " expected i == j"
>   << std::endl;
> ret = 1;
> break;
> }
> }
> return ret;
> }
> {code}
> 1. Output from GCC 4.5.0:
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:16:34][2162]>> ./test-gcc
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:16:48][2163]>> echo $status
> 0
> {noformat}
> 2. Output from Sun C++ 12.2 with stlport:
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:16:50][2164]>> ./test-ss122-stlport 
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771

[jira] [Updated] (STDCXX-1057) attempting to create a std::string of size 65535 or greater fails with Perennial CPPVS V8.1

2012-02-07 Thread Travis Vitek (Updated) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/STDCXX-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Travis Vitek updated STDCXX-1057:
-

Comment: was deleted

(was: I agree with Martin. I'll even go further to say that the testcase is 
incorrect in that it expects an allocation larger than 
{{test_allocator::max_size()}} to succeed.


)

> attempting to create a std::string of size 65535 or greater fails with 
> Perennial CPPVS V8.1
> ---
>
> Key: STDCXX-1057
> URL: https://issues.apache.org/jira/browse/STDCXX-1057
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 21. Strings
>Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
> Environment: Solaris 10 and 11, RedHat Linux, OpenSuSE Linux
> SUN C++ Compilers 12.1, 12.2, 12.3
> Defect is independent of compiler and platform
>Reporter: Stefan Teleman
>  Labels: conformance, features, standards, test
> Fix For: 4.2.x, 4.3.x, 5.0.0
>
> Attachments: stdcxx-1057.patch, test.cc
>
>
> in member function:
> size_type basic_string<_CharT, _Traits, _Allocator>::max_size();
> the maximum size of a basic_string is restricted to less than 65535 bytes.
> The Standard is ambiguous as to what the max_size() of a std::string should
> actually be (see LWG Core Issue 197). However, less than 65535 bytes for
> the max_size of a std::string is rather small. GNU libstdc++ and stlport4
> set std::string::max_size to (SIZE_MAX / 4) (i.e. 1GB). Solaris sets it
> to SIZE_MAX.
> Perennial CPPVS explicitly tests for the creation of a std::string of size
> greater than 65535. In the current stdcxx implementation, this test fails.
> The max_size of a std::string should be significantly greater than 65535 
> bytes.
> Test to reproduce the defect:
> {code:title=test.cc|borderStyle=solid}
> #include 
> #include 
> const size_t maxlen = 65536U;
> char array[maxlen];
> struct test_traits : public std::char_traits
> { };
> template
> struct test_alloc : public std::allocator
> {
> typedef typename std::allocator::size_type size_type;
> template
> struct rebind
> {
> typedef test_alloc other;
> };
> test_alloc() throw() { }
> test_alloc(const test_alloc& rhs) throw() { }
> template
> test_alloc(const test_alloc& y) throw() { }
> ~test_alloc() throw() { }
> size_type max_size() const throw() { return maxlen; }
> };
> int main()
> {
> typedef
> std::basic_string > test_string;
> int ret = 0;
> size_t i, j;
> for (i = 0; i < maxlen; i++)
> array[i] = '*';
> array[maxlen - 1] = '\0';
> for (i = 0; i < maxlen - 1; i+= 8)
> {
> array[i] = '\0';
> test_string s(array);
> j = s.size();
> array[i] = '-';
> if (i != j)
> {
> std::cerr << "i = " << i << " j = " << j << " expected i == j"
>   << std::endl;
> ret = 1;
> break;
> }
> }
> return ret;
> }
> {code}
> 1. Output from GCC 4.5.0:
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:16:34][2162]>> ./test-gcc
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:16:48][2163]>> echo $status
> 0
> {noformat}
> 2. Output from Sun C++ 12.2 with stlport:
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:16:50][2164]>> ./test-ss122-stlport 
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:16:58][2165]>> echo $status
> 0
> {noformat}
> 3. Output from Sun C++ 12.2 with our patched stdcxx:
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:17:00][2166]>> ./test-ss122-stdcxx 
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:17:06][2167]>> echo $status
> 0
> {noformat}
> 4. Output from Pathscale 4.0.12.1 (which did not patch stdcxx):
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:17:08][2168]>> ./test-pathscale 
> Terminating due to uncaught exception 0x614240 of type std::length_error
> Abort (core dumped)
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
>  10:17:13][2169]>> echo $status
> 134
> {noformat}
> Patch for 4.2.1 to follow shortly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/ji