[jira] [Commented] (STDCXX-1061) std::valarray<>::operator&& () produces wrong result
[
https://issues.apache.org/jira/browse/STDCXX-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204044#comment-13204044
]
Travis Vitek commented on STDCXX-1061:
--
Submitted as
[r1242128|http://svn.apache.org/viewvc?view=revision&revision=1242128].
> std::valarray<>::operator&& () produces wrong result
>
>
> Key: STDCXX-1061
> URL: https://issues.apache.org/jira/browse/STDCXX-1061
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 23. Containers
>Affects Versions: 4.2.1
> Environment: Solaris 10 and 11
> Red Hat Linux
> OpenSuSE Linux
> SunPro C++ 12.1, 12.2, 12.3
> Defect is independent of platform and/or compiler.
>Reporter: Stefan Teleman
>Assignee: Travis Vitek
> Labels: conformance, standards
> Fix For: 4.2.x, 4.3.x, 5.0.0
>
> Attachments: stdcxx-1061.patch
>
>
> std::valarray<>::operator&& () produces wrong result:
> {code:title=test.cc|borderStyle=solid}
> #include
> #include
> static const size_t maxlen = 10;
> void print(const std::valarray& v)
> {
> for (size_t i = 0; i < maxlen; ++i)
> std::cerr << v[i] << " ";
> std::cerr << std::endl;
> }
> int main()
> {
> int nonzero[maxlen] = { 0, 1, 0, 3, 0, -5, 0, -7, 0, -11 };
> int one = 1;
> int ret = 0;
> size_t i;
> std::valarray v0 (nonzero, maxlen);
> std::valarray v3 (maxlen);
> for (i = 0; i < maxlen; i++)
> v3[i] = nonzero[i] && one;
> std::valarray v1 = std::operator&& (v0, one);
> for (i = 0; i < maxlen; i++)
> {
> if ((nonzero[i] && one) != v1[i])
> ret = 1;
> }
> if (ret)
> {
> std::cerr << "expected: ";
> print (v3);
> std::cerr << "got: ";
> print (v1);
> }
> return ret;
> }
> {code}
> 1. Output from GCC 4.5.0:
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/nothrow][02/08/2012
> 13:22:47][2463]>> ./v-gcc
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/nothrow][02/08/2012
> 13:23:01][2464]>> echo $status
> 0
> {noformat}
> 2. Output from SunPro C++ 12.2 with stlport4:
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/nothrow][02/08/2012
> 13:23:02][2465]>> ./v-ss122-stlport
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/nothrow][02/08/2012
> 13:23:08][2466]>> echo $status
> 0
> {noformat}
> 3. Output from SunPro C++ 12.2 with our patched stdcxx:
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/nothrow][02/08/2012
> 13:23:10][2467]>> ./v-ss122-stdcxx
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/nothrow][02/08/2012
> 13:23:18][2468]>> echo $status
> 0
> {noformat}
> 4. Output from Pathscale 4.0.12.1 (which didn't patch stdcxx):
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/nothrow][02/08/2012
> 13:23:20][2469]>> ./v-pathscale
> expected: 0 1 0 1 0 1 0 1 0 1
> got: 0 1 0 0 0 0 0 0 0 0
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/nothrow][02/08/2012
> 13:23:24][2470]>> echo $status
> 1
> {noformat}
> Patch for stdcxx 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
[
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
[
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] [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-tabpanel&focusedCommentId=13201791#comment-13201791
]
Travis Vitek commented on STDCXX-1057:
--
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. Overriding {{allocate()}} to throw {{bad_alloc}} when such a
request occurs should result in the testcase throwing.
> 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 administr
[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-tabpanel&focusedCommentId=13201788#comment-13201788
]
Travis Vitek commented on STDCXX-1055:
--
Stefan,
I can most definitely tell if the base class destructor is virtual or not.
Invoking a function (including the destructor) via base class pointer or
reference will invoke the derived class version of that function if it is
virtual. This is the basis for polymorphism in C++, and that is exactly what my
testcase does.
My test shows two things.
# Other implementations of the C++ Standard Library don't have virtual
destructors for these classes.
# If someone were to write a class deriving from {{time_base}}, and their code
relied on {{time_base}} having a virtual destructor, the destructor for their
derived class may not get called (if it is deleted via a base class pointer).
As for making the destructors protected, I think Martin will agree (eventually)
that they should be (he did supply the testcase and fix for STDCXX-469 for a
similar issue in {{std::locale::facet}}). The issues that we are currently
quibbling over is where in the inheritance tree the destructor is supposed to
be virtual and how to create a testcase that is well-formed and can verify that
the destructors in the derived classes are protected and not public or private.
> 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-tabpanel&focusedCommentId=13201710#comment-13201710
]
Travis Vitek commented on STDCXX-1055:
--
{quote="Stefan Teleman"}
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 classes' destructors at all
{quote}
As you see from your snippet, the C++ Standard doesn't explicitly list them in
the interface and as far as I can tell, it doesn't require them. As mentioned
previously, they are only required in the derived facet classes (which get it
from their other base {{std::locale::facet}}).
As you pointed out above, relying on these classes having behavior not required
by the standard _leads to writing very unportable code_. Example...
{code}
#include
#include
bool virtual_destructor = false;
struct A : std::time_base
{
/* virtual */ ~A() {
virtual_destructor = true;
}
};
int main ()
{
std::time_base* p = new A;
delete p;
assert (virtual_destructor);
}
{code}
This code assumes that the destructor in the base is virtual. It is
non-portable. It asserts on gcc-4.3.4, gcc-4.4.5, sunpro-5.10 using stlport4
and the default standard library, as well as acc-6.25. The test runs to
completion (implying that the destructor is virtual) on msvc-11.0 and
vacpp-11.1.
If you have some sort of conformance test that verifies the destructor of these
bases is virtual, I'm going to suggest that the conformance test is incorrect,
or is at least verifying conformance with the Dinkumware C++ Standard Library.
> 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-tabpanel&focusedCommentId=13201523#comment-13201523
]
Travis Vitek commented on STDCXX-1055:
--
I'm also unsure how (1) would be detectable and would be interested to see a
testcase. That said, there seems to be a mix of class/struct among the locale
and locale facet classes. I don't see any reason to not unconditionally fix
this, provided it doesn't break due to name mangling on some platforms.
It appears that a conditional fix was put into place for (2) for STDCXX-469. It
should be automatically enabled for all compilers non Microsoft compilers now,
and will be automatically fixed for Microsoft if/when stdcxx has a major
release.
Finally, it seems that (3) would be easy to detect, but I see nothing in the
standard that requires the {{*_base}} classes to have virtual destructors. The
derived classes must, but that virtual destructor for those classes should come
from the base {{std::locale::facet}}.
> 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-1059) std::ios_base::setf() and std::ios_base::unsetf() do not set/clear the format flags correctly
[
https://issues.apache.org/jira/browse/STDCXX-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201459#comment-13201459
]
Travis Vitek commented on STDCXX-1059:
--
According to C++03, all of the functions are required to take/return values.
{noformat}
// 27.4.2.2 fmtflags state:
fmtflags flags() const;
fmtflags flags(fmtflags fmtfl);
fmtflags setf(fmtflags fmtfl);
fmtflags setf(fmtflags fmtfl, fmtflags mask);
void unsetf(fmtflags mask);
{noformat}
In your {{flags.cc}} example, it seems to me that the problem is
{{flags(fmtflags)}} is supposed to set the underlying flags member directly,
not mask it in.
{noformat}
fmtflags flags(fmtflags fmtfl);
2 Postcondition: fmtfl == flags().
3 Returns: The previous value of flags().
fmtflags setf(fmtflags fmtfl);
4 Effects: Sets fmtfl in flags().
5 Returns: The previous value of flags().
{noformat}
It looks to me like the implementations of {{setf()}} and {{unsetf()}} are
correct, and there is some sort of bug in {{flags()}}.
> std::ios_base::setf() and std::ios_base::unsetf() do not set/clear the format
> flags correctly
> -
>
> Key: STDCXX-1059
> URL: https://issues.apache.org/jira/browse/STDCXX-1059
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
>Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
> Environment: Solaris 10 and 11
> Red Hat Linux, OpenSuSE Linux
> Sun C++ Compilers 12.1, 12.2, 12.3
> Defect is independent of platform and/or compiler
>Reporter: Stefan Teleman
> Labels: conformance, runtime, standards
> Fix For: 4.2.2, 4.2.x, 4.3.x, 5.0.0
>
> Attachments: flags.cc, test.cc
>
>
> std::ios_base::setf (fmtflags fl) and std::ios_base::unsetf (fmtflags fl)
> do not set or clear the format flags correctly:
> {code:title=test.cc|borderStyle=solid}
> #include
> #include
> #include
> int main()
> {
> std::fstream strm;
> std::ios_base::fmtflags fl;
> int ret = 0;
> fl = std::ios_base::dec;
> strm.unsetf(fl);
> fl = std::ios_base::hex;
> strm.setf(fl);
> strm.unsetf(fl);
> if (strm.flags() & fl)
> {
> std::cerr << "failure to clear hex flags" << std::endl;
> ++ret;
> }
> return ret;
> }
> {code}
> 1. Output from GCC 4.5.0:
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/fmtflags][02/05/2012
> 15:19:37][1957]>> ./test-gcc
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/fmtflags][02/05/2012
> 15:20:02][1958]>> echo $status
> 0
> {noformat}
> 2. Output from Sun C++ 12.2 with stlport:
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/fmtflags][02/05/2012
> 15:20:24][1959]>> ./test-ss122-stlport
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/fmtflags][02/05/2012
> 15:21:08][1960]>> echo $status
> 0
> {noformat}
> 3. Output rom Sun C++ 12.2 with our patched stdcxx:
> {noformat}
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/fmtflags][02/05/2012
> 15:21:09][1961]>> ./test-ss122-stdcxx
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/fmtflags][02/05/2012
> 15:21:44][1962]>> 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/fmtflags][02/05/2012
> 15:21:46][1963]>> ./test-pathscale
> failure to clear hex flags
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/fmtflags][02/05/2012
> 15:22:48][1964]>> echo $status
> 1
> {noformat}
> Simplified test case identifying the problem:
> {code:title=flags.cc|borderStyle=solid}
> #include
> #include
> class BadTest
> {
> public:
> BadTest() : _flags(0) { }
> ~BadTest() { }
> unsigned int flags() const { return _flags; }
> unsigned int flags (unsigned int f)
> {
> unsigned int ret = _flags;
> _flags |= f;
> return ret;
> }
> unsigned int setf (unsigned int f) { return flags (flags() | f); }
> void unsetf (unsigned int f) { flags (flags() & ~f); }
> private:
> unsigned int _flags;
> };
> class GoodTest
> {
> public:
> GoodTest() : _flags(0) { }
> ~GoodTest() { }
> unsigned int flags() const { return _flags; }
> unsigned int flags (unsigned int f)
> {
> unsigned int ret = _flags;
> _flags |= f;
> return ret;
> }
> unsigned int setf (unsigned int f)
> {
> unsigned int ret = _flags;
> _flags |= f;
> return ret;
> }
> void unsetf (unsigned int f) { _flags &= ~f; }
> private:
> unsigned int _flags;
> };
> int
