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

[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] [Commented] (STDCXX-1057) attempting to create a std::string of size 65535 or greater fails with Perennial CPPVS V8.1

[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

[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

[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

[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-1055) some of the localization class declarations do not follow the ISO/IEC:14882:2003 specification

[Stefan Teleman (Commented) (JIRA)]

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

Stefan Teleman commented on STDCXX-1055:


We could #ifdef _RWSTD_STRICT_ANSI guard it in 4.3.x.


> some of the localization class declarations do not follow the 
> ISO/IEC:14882:2003 specification
> --
>
> Key: STDCXX-1055
> URL: https://issues.apache.org/jira/browse/STDCXX-1055
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 22. Localization
>Affects Versions: 4.2.1, 4.2.2, 4.2.x, 4.3.x, 5.0.0
> Environment: Solaris 10 and 11, Linux (RedHat and OpenSUSE), Sun C++ 
> Compiler 12.1, 12.2, 12.3, GCC4.
> The defect is independent of platform or compiler.
>Reporter: Stefan Teleman
>  Labels: conformance, standards
> Fix For: 4.2.x, 4.3.x, 5.0.0
>
> Attachments: stdcxx-1055.patch
>
>
> For the following classes:
> std::codecvt<> and its specializations
> std::collate<> and its specializations
> std::ctype<> and its specializations
> std::ctype_byname<> and its specializations
> std::messages<> and its specializations
> std::messages_byname<> and its specializations
> std::money_get<> and its specializations
> std::moneypunct<> and is specializations
> std::moneypunct_byname<> and its specializations
> std::money_put<> and its specializations
> std::num_get<> and its specializations
> std::numpunct<> and its specializations
> std::numpunct_byname<> and its specializations
> std::num_put<> and its specializations
> std::time_get<> and its specializations
> std::time_get_byname<> and its specializations
> std::time_put<> and its specializations
> 1. all these type declarations must be of class type (and not of struct type)
> 2. all these classes must have protected virtual destructors
> 3. all the corresponding *_base (time_base, money_base, etc), must have 
> virtual destructors
> The current implementation of these types as structs (with default public 
> access
> specifier on their non-virtual destructors) causes failures in Perennial 
> CPPVS V8.1.
> Changing the access specifier for these destructors requires some changes in 
> the
> stdcxx tests for localization.
> Patch based on 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/jira

[jira] [Commented] (STDCXX-1055) some of the localization class declarations do not follow the ISO/IEC:14882:2003 specification

[Stefan Teleman (Commented) (JIRA)]

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

Stefan Teleman commented on STDCXX-1055:


{code:title=test_non_virtual.cc|borderStyle=solid}
#include 

class foo_base
{
public:
enum { one, two, three, four, five };

foo_base() { }
~foo_base() { std::cerr << "foo_base::~foo_base()" << std::endl; }
virtual void print() = 0; // because I don't like casting
};

class bar
{
public:
bar() { }
virtual ~bar() { std::cerr << "virtual bar::~bar()" << std::endl; }
};

class foobar : public foo_base, public bar
{
public:
foobar() { }
virtual ~foobar() { std::cerr << "virtual foobar::~foobar()" << std::endl; }

virtual void print()
{
std::cerr << "one: " << one << " two: " << two << " three: "
  << three << " four: " << four << " five: " << five
  << std::endl;
}
};

int main()
{
foo_base* fb = new foobar();

fb->print();
delete fb;

std::cerr.flush();

return 0;
}
{code}

{code:title=test_virtual.cc|borderStyle=solid}
#include 

class foo_base
{
public:
enum { one, two, three, four, five };

foo_base() { }
virtual ~foo_base()
{ std::cerr << "virtual foo_base::~foo_base()" << std::endl; }
virtual void print() = 0; // I don't like casting here either
};

class bar
{
public:
bar() { }
virtual ~bar() { std::cerr << "virtual bar::~bar()" << std::endl; }
};

class foobar : public foo_base, public bar
{
public:
foobar() { }
virtual ~foobar() { std::cerr << "virtual foobar::~foobar()" << std::endl; }

virtual void print()
{
std::cerr << "one: " << one << " two: " << two << " three: "
  << three << " four: " << four << " five: " << five
  << std::endl;
}
};

int main()
{
foo_base* fb = new foobar();

fb->print();
delete fb;

std::cerr.flush();

return 0;
}
{code}

Output from GCC 4.5.0, SunPro C++ 12.2 with the default libCstd, SunPro C++ 
12.2 with stlport, Pathscale 4.0.12.1:

{noformat}
[steleman@darthvader][/src/steleman/programming/stdcxx-upstream-patches/jira-patches][02/06/2012
 18:48:56][2229]>> ./test_non_virtual_gcc 
one: 0 two: 1 three: 2 four: 3 five: 4
foo_base::~foo_base()
[steleman@darthvader][/src/steleman/programming/stdcxx-upstream-patches/jira-patches][02/06/2012
 18:50:46][2230]>> ./test_non_virtual_cstd
one: 0 two: 1 three: 2 four: 3 five: 4
foo_base::~foo_base()
[steleman@darthvader][/src/steleman/programming/stdcxx-upstream-patches/jira-patches][02/06/2012
 18:50:56][2231]>> ./test_non_virtual_stlport
one: 0 two: 1 three: 2 four: 3 five: 4
foo_base::~foo_base()
[steleman@darthvader][/src/steleman/programming/stdcxx-upstream-patches/jira-patches][02/06/2012
 18:51:00][2232]>> ./test_non_virtual_pathscale
one: 0 two: 1 three: 2 four: 3 five: 4
foo_base::~foo_base()
{noformat}

Do we leak? Yes, we do.

{noformat}
[steleman@darthvader][/src/steleman/programming/stdcxx-upstream-patches/jira-patches][02/06/2012
 18:51:05][2233]>> ./test_virtual_gcc
one: 0 two: 1 three: 2 four: 3 five: 4
virtual foobar::~foobar()
virtual bar::~bar()
virtual foo_base::~foo_base()
[steleman@darthvader][/src/steleman/programming/stdcxx-upstream-patches/jira-patches][02/06/2012
 18:51:10][2234]>> ./test_virtual_cstd
one: 0 two: 1 three: 2 four: 3 five: 4
virtual foobar::~foobar()
virtual bar::~bar()
virtual foo_base::~foo_base()
[steleman@darthvader][/src/steleman/programming/stdcxx-upstream-patches/jira-patches][02/06/2012
 18:51:14][2235]>> ./test_virtual_stlport
one: 0 two: 1 three: 2 four: 3 five: 4
virtual foobar::~foobar()
virtual bar::~bar()
virtual foo_base::~foo_base()
[steleman@darthvader][/src/steleman/programming/stdcxx-upstream-patches/jira-patches][02/06/2012
 18:51:18][2236]>> ./test_virtual_pathscale
one: 0 two: 1 three: 2 four: 3 five: 4
virtual foobar::~foobar()
virtual bar::~bar()
virtual foo_base::~foo_base()
{noformat}

Do we leak? No, we don't.



> some of the localization class declarations do not follow the 
> ISO/IEC:14882:2003 specification
> --
>
> Key: STDCXX-1055
> URL: https://issues.apache.org/jira/browse/STDCXX-1055
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 22. Localization
>Affects Versions: 4.2.1, 4.2.2, 4.2.x, 4.3.x, 5.0.0
> Environment: Solaris 10 and 11, Linux (RedHat and OpenSUSE), Sun C++ 
> Compiler 12.1, 12.2, 12.3, GCC4.
> The defect is independent of platform or compiler.
>Reporter: Stefan Teleman
>  Labels: conformance, standards
> Fix For: 4.2.x, 4.3.x, 5.0.0
>
> Attachments: stdcxx-1055.patch
>
>
> For the following classes:
> std::codecvt<> and its specializations
> s

[jira] [Commented] (STDCXX-1055) some of the localization class declarations do not follow the ISO/IEC:14882:2003 specification

[Stefan Teleman (Commented) (JIRA)]

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

Stefan Teleman commented on STDCXX-1055:


You aren't verifying that the destructor is virtual or not, because you can't 
really do that without looking inside the __vtbl. You are testing for the value 
of bool virtual_destructor. This variable has nothing to do with the interface 
specification of your class. It isn't even a member of the class. I am not sure 
what this proves.

You are correct: the Standard doesn't require virtual destructors. It doesn't 
*forbid* them, either.

Is there such a variable (bool virtual_destructor) in money_base or time_base 
which would allow for this test?

Also, I am a bit confused at the assertion that "destructors cannot be virtual" 
(in spite of the fact that there is no way of testing for them), but breaking 
the interface specification of all the localization classes by making their 
destructors public, and therefore allowing direct instantiation, is somehow OK. 
I will submit that one of the purposes of making all these destructors 
protected *was* to make direct instantiation impossible.





> some of the localization class declarations do not follow the 
> ISO/IEC:14882:2003 specification
> --
>
> Key: STDCXX-1055
> URL: https://issues.apache.org/jira/browse/STDCXX-1055
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 22. Localization
>Affects Versions: 4.2.1, 4.2.2, 4.2.x, 4.3.x, 5.0.0
> Environment: Solaris 10 and 11, Linux (RedHat and OpenSUSE), Sun C++ 
> Compiler 12.1, 12.2, 12.3, GCC4.
> The defect is independent of platform or compiler.
>Reporter: Stefan Teleman
>  Labels: conformance, standards
> Fix For: 4.2.x, 4.3.x, 5.0.0
>
> Attachments: stdcxx-1055.patch
>
>
> For the following classes:
> std::codecvt<> and its specializations
> std::collate<> and its specializations
> std::ctype<> and its specializations
> std::ctype_byname<> and its specializations
> std::messages<> and its specializations
> std::messages_byname<> and its specializations
> std::money_get<> and its specializations
> std::moneypunct<> and is specializations
> std::moneypunct_byname<> and its specializations
> std::money_put<> and its specializations
> std::num_get<> and its specializations
> std::numpunct<> and its specializations
> std::numpunct_byname<> and its specializations
> std::num_put<> and its specializations
> std::time_get<> and its specializations
> std::time_get_byname<> and its specializations
> std::time_put<> and its specializations
> 1. all these type declarations must be of class type (and not of struct type)
> 2. all these classes must have protected virtual destructors
> 3. all the corresponding *_base (time_base, money_base, etc), must have 
> virtual destructors
> The current implementation of these types as structs (with default public 
> access
> specifier on their non-virtual destructors) causes failures in Perennial 
> CPPVS V8.1.
> Changing the access specifier for these destructors requires some changes in 
> the
> stdcxx tests for localization.
> Patch based on 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/jira

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

[Stefan Teleman (Commented) (JIRA)]

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

Stefan Teleman commented on STDCXX-1057:


For this particular case, the Standard doesn't really specify a behavior, by 
virtue of the fact that it is ambiguous. There are several possible 
interpretations:

{noformat}
1. 20.1.5, t32 "the largest value that can meaningfully be passed to 
X::allocate()"
2. 23.1, t65 "size() of the largest possible container"
3. 21.3.3., p3 "The maximum size of the string -- see 23.1, t65"
4. LWG Core Issue 197
{noformat}

The question then becomes "what do other known sane implementations do?"


> 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:1

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

[Stefan Teleman (Commented) (JIRA)]

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

Stefan Teleman commented on STDCXX-1056:


I understand the need for writing small and efficient methods, but I don't 
agree that the problem reported in STDCXX-839 relates to the test running for 
too long. The fact that the test program doesn't terminate or abends with 
SIGHUP is a symptom of undefined run-time behavior.

{noformat}
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/stdcxx-4.2.1/build/tests][02/06/2012
 16:49:50][1512]>> /usr/bin/time -p ./22.locale.numpunct.mt --nthreads=4 
--nloops=100 >& t.out
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/stdcxx-4.2.1/build/tests][02/06/2012
 16:50:13][1513]>> tail -17 t.out

# 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% |
# +---+--+--+--+
real 4.95
user 1.07
sys 0.22
{noformat}

This test case (and the corresponding 22.locale.moneypunct.mt) consistently 
exhibit run-time crashes or insane behavior (CPU being pinned at 99% forever) 
without the serialization fix.

The interesting part is where this race condition actually happens: it's in 
include/loc/_num_put.cc:

{code title=_num_put.cc|borderStyle=solid}

template  */>
_TYPENAME num_put<_CharT, _OutputIter>::iter_type
num_put<_CharT, _OutputIter>::
_C_put (iter_type __it, ios_base &__flags, char_type __fill, int __type,
const void *__pval) const
{
const numpunct &__np =
_RWSTD_USE_FACET (numpunct, __flags.getloc ());

char __buf [_RWSTD_DBL_MAX_10_EXP];

// will grow as necessary and may need to be deleted
char *__pbuf = __buf;

const string__grouping = __np.grouping (); // <- !!
const char* const   __grp  = __grouping.c_str (); // <- !!
const _RWSTD_STREAMSIZE __prec = __flags.precision ();
// [ ... ]
{code}



> 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: 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-1055) some of the localization class declarations do not follow the ISO/IEC:14882:2003 specification

[Stefan Teleman (Commented) (JIRA)]

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

Stefan Teleman commented on STDCXX-1055:


About the protected virtual destructors:

The Standard specification is very explicit about declaring all these 
destructors protected virtual. I checked C++1998, C++2003 and C+2011, and in 
all three Standard specifications, these destructors are protected.

Allowing them to be public by default (and not as a stdcxx extension) leads to 
writing very unportable code - which I guess goes against the purpose of having 
a Standard in the first place. Not to mention that it is a violation of the 
Standard spec.

I am not sure I understand the advantage of having these destructors public.


> some of the localization class declarations do not follow the 
> ISO/IEC:14882:2003 specification
> --
>
> Key: STDCXX-1055
> URL: https://issues.apache.org/jira/browse/STDCXX-1055
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 22. Localization
>Affects Versions: 4.2.1, 4.2.2, 4.2.x, 4.3.x, 5.0.0
> Environment: Solaris 10 and 11, Linux (RedHat and OpenSUSE), Sun C++ 
> Compiler 12.1, 12.2, 12.3, GCC4.
> The defect is independent of platform or compiler.
>Reporter: Stefan Teleman
>  Labels: conformance, standards
> Fix For: 4.2.x, 4.3.x, 5.0.0
>
> Attachments: stdcxx-1055.patch
>
>
> For the following classes:
> std::codecvt<> and its specializations
> std::collate<> and its specializations
> std::ctype<> and its specializations
> std::ctype_byname<> and its specializations
> std::messages<> and its specializations
> std::messages_byname<> and its specializations
> std::money_get<> and its specializations
> std::moneypunct<> and is specializations
> std::moneypunct_byname<> and its specializations
> std::money_put<> and its specializations
> std::num_get<> and its specializations
> std::numpunct<> and its specializations
> std::numpunct_byname<> and its specializations
> std::num_put<> and its specializations
> std::time_get<> and its specializations
> std::time_get_byname<> and its specializations
> std::time_put<> and its specializations
> 1. all these type declarations must be of class type (and not of struct type)
> 2. all these classes must have protected virtual destructors
> 3. all the corresponding *_base (time_base, money_base, etc), must have 
> virtual destructors
> The current implementation of these types as structs (with default public 
> access
> specifier on their non-virtual destructors) causes failures in Perennial 
> CPPVS V8.1.
> Changing the access specifier for these destructors requires some changes in 
> the
> stdcxx tests for localization.
> Patch based on 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/jira

[jira] [Commented] (STDCXX-1055) some of the localization class declarations do not follow the ISO/IEC:14882:2003 specification

[Stefan Teleman (Commented) (JIRA)]

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

Stefan Teleman commented on STDCXX-1055:


It is not true that money_base and time_base are not allowed to have virtual 
destructors. The Standard specification does not provide any declaration for
these claseses' destructors at all:

22.2.6.3:

{code:title=22.2.6.3|borderStyle=solid}
namesapce std {
class money_base {
public:
enum part { none, space, symbol, sign, value };
struct pattern { char field[4]; };
};

[ ... ]
{code}





> some of the localization class declarations do not follow the 
> ISO/IEC:14882:2003 specification
> --
>
> Key: STDCXX-1055
> URL: https://issues.apache.org/jira/browse/STDCXX-1055
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 22. Localization
>Affects Versions: 4.2.1, 4.2.2, 4.2.x, 4.3.x, 5.0.0
> Environment: Solaris 10 and 11, Linux (RedHat and OpenSUSE), Sun C++ 
> Compiler 12.1, 12.2, 12.3, GCC4.
> The defect is independent of platform or compiler.
>Reporter: Stefan Teleman
>  Labels: conformance, standards
> Fix For: 4.2.x, 4.3.x, 5.0.0
>
> Attachments: stdcxx-1055.patch
>
>
> For the following classes:
> std::codecvt<> and its specializations
> std::collate<> and its specializations
> std::ctype<> and its specializations
> std::ctype_byname<> and its specializations
> std::messages<> and its specializations
> std::messages_byname<> and its specializations
> std::money_get<> and its specializations
> std::moneypunct<> and is specializations
> std::moneypunct_byname<> and its specializations
> std::money_put<> and its specializations
> std::num_get<> and its specializations
> std::numpunct<> and its specializations
> std::numpunct_byname<> and its specializations
> std::num_put<> and its specializations
> std::time_get<> and its specializations
> std::time_get_byname<> and its specializations
> std::time_put<> and its specializations
> 1. all these type declarations must be of class type (and not of struct type)
> 2. all these classes must have protected virtual destructors
> 3. all the corresponding *_base (time_base, money_base, etc), must have 
> virtual destructors
> The current implementation of these types as structs (with default public 
> access
> specifier on their non-virtual destructors) causes failures in Perennial 
> CPPVS V8.1.
> Changing the access specifier for these destructors requires some changes in 
> the
> stdcxx tests for localization.
> Patch based on 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/jira

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

[Stefan Teleman (Commented) (JIRA)]

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

Stefan Teleman commented on STDCXX-1056:


Test cases for this defect are:

22.locale.moneypunct.mt and 22.locale.numpunct.mt.

See also STDCXX-839:

https://issues.apache.org/jira/browse/STDCXX-839


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