[jira] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe
[
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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::numpunctcharT 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::numpunctchar
# 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::numpunctwchar_t
# 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::numpunctchar and std::numpunctwchar_t
# 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 creation of the std::string being returned by value.
Patch for 4.2.1 to follow.
--
This
[jira] [Commented] (STDCXX-1057) attempting to create a std::string of size 65535 or greater fails with Perennial CPPVS V8.1
[
https://issues.apache.org/jira/browse/STDCXX-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 iostream
#include string
const size_t maxlen = 65536U;
char array[maxlen];
struct test_traits : public std::char_traitschar
{ };
templateclass T
struct test_alloc : public std::allocatorT
{
typedef typename std::allocatorT::size_type size_type;
templateclass Y
struct rebind
{
typedef test_allocY other;
};
test_alloc() throw() { }
test_alloc(const test_alloc rhs) throw() { }
templateclass Y
test_alloc(const test_allocY y) throw() { }
~test_alloc() throw() { }
size_type max_size() const throw() { return maxlen; }
};
int main()
{
typedef
std::basic_stringchar, test_traits, test_allocchar 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/jira
[jira] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe
[ https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[
https://issues.apache.org/jira/browse/STDCXX-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 iostream
#include string
const size_t maxlen = 65536U;
char array[maxlen];
struct test_traits : public std::char_traitschar
{ };
templateclass T
struct test_alloc : public std::allocatorT
{
typedef typename std::allocatorT::size_type size_type;
templateclass Y
struct rebind
{
typedef test_allocY other;
};
test_alloc() throw() { }
test_alloc(const test_alloc rhs) throw() { }
templateclass Y
test_alloc(const test_allocY y) throw() { }
~test_alloc() throw() { }
size_type max_size() const throw() { return maxlen; }
};
int main()
{
typedef
std::basic_stringchar, test_traits, test_allocchar 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
[jira] [Commented] (STDCXX-1055) some of the localization class declarations do not follow the ISO/IEC:14882:2003 specification
[ https://issues.apache.org/jira/browse/STDCXX-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-1055) some of the localization class declarations do not follow the ISO/IEC:14882:2003 specification
[
https://issues.apache.org/jira/browse/STDCXX-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13201837#comment-13201837
]
Stefan Teleman commented on STDCXX-1055:
{code:title=test_non_virtual.cc|borderStyle=solid}
#include iostream
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 iostream
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
std::collate and its specializations
std::ctype and its specializations
std::ctype_byname and its specializations
[jira] [Commented] (STDCXX-1055) some of the localization class declarations do not follow the ISO/IEC:14882:2003 specification
[ https://issues.apache.org/jira/browse/STDCXX-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-1056) std::moneypunct and std::numpunct implementations are not thread-safe
[ https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
