[jira] Commented: (STDCXX-430) building Boost with stdcxx
[ https://issues.apache.org/jira/browse/STDCXX-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554907 ] Farid Zaripov commented on STDCXX-430: -- The new tickets in boost tracking systm: http://svn.boost.org/trac/boost/ticket/1542 http://svn.boost.org/trac/boost/ticket/1543 http://svn.boost.org/trac/boost/ticket/1545 http://svn.boost.org/trac/boost/ticket/1547 building Boost with stdcxx -- Key: STDCXX-430 URL: https://issues.apache.org/jira/browse/STDCXX-430 Project: C++ Standard Library Issue Type: Improvement Components: External Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Farid Zaripov Priority: Critical Fix For: 4.2.1 Attachments: boost-1.34.1.patch, boost_regress_gcc.zip, boost_regress_sun.zip, boost_regress_win.zip This is a placeholder issue to make it possible and easy to build the Boost libraries on top of stdcxx. Each stdcxx bug revealed by Boost must have an issue. The issue should be linked to this one. Changes contributed to Boost (such as stdcxx .jam files) should be tracked as subtasks of this issue. Each bug in Boost should be filed in the Boost bug tracking database and cross-referenced in comments on this issue. See the following threads for details of the project: http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg02910.html http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03089.html http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03410.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (STDCXX-430) building Boost with stdcxx
[ https://issues.apache.org/jira/browse/STDCXX-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554907 ] farid edited comment on STDCXX-430 at 12/29/07 3:07 AM: The new tickets in boost tracking system: http://svn.boost.org/trac/boost/ticket/1542 http://svn.boost.org/trac/boost/ticket/1543 http://svn.boost.org/trac/boost/ticket/1545 http://svn.boost.org/trac/boost/ticket/1547 was (Author: farid): The new tickets in boost tracking systm: http://svn.boost.org/trac/boost/ticket/1542 http://svn.boost.org/trac/boost/ticket/1543 http://svn.boost.org/trac/boost/ticket/1545 http://svn.boost.org/trac/boost/ticket/1547 building Boost with stdcxx -- Key: STDCXX-430 URL: https://issues.apache.org/jira/browse/STDCXX-430 Project: C++ Standard Library Issue Type: Improvement Components: External Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Farid Zaripov Priority: Critical Fix For: 4.2.1 Attachments: boost-1.34.1.patch, boost_regress_gcc.zip, boost_regress_sun.zip, boost_regress_win.zip This is a placeholder issue to make it possible and easy to build the Boost libraries on top of stdcxx. Each stdcxx bug revealed by Boost must have an issue. The issue should be linked to this one. Changes contributed to Boost (such as stdcxx .jam files) should be tracked as subtasks of this issue. Each bug in Boost should be filed in the Boost bug tracking database and cross-referenced in comments on this issue. See the following threads for details of the project: http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg02910.html http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03089.html http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03410.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-430) building Boost with stdcxx
[ https://issues.apache.org/jira/browse/STDCXX-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-430: - Attachment: boost_regress_sun.zip boost_regress_gcc.zip building Boost with stdcxx -- Key: STDCXX-430 URL: https://issues.apache.org/jira/browse/STDCXX-430 Project: C++ Standard Library Issue Type: Improvement Components: External Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Farid Zaripov Priority: Critical Fix For: 4.2.1 Attachments: boost-1.34.1.patch, boost_regress_gcc.zip, boost_regress_sun.zip, boost_regress_win.zip This is a placeholder issue to make it possible and easy to build the Boost libraries on top of stdcxx. Each stdcxx bug revealed by Boost must have an issue. The issue should be linked to this one. Changes contributed to Boost (such as stdcxx .jam files) should be tracked as subtasks of this issue. Each bug in Boost should be filed in the Boost bug tracking database and cross-referenced in comments on this issue. See the following threads for details of the project: http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg02910.html http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03089.html http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03410.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-430) building Boost with stdcxx
[ https://issues.apache.org/jira/browse/STDCXX-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-430: - Attachment: boost_regress_win.zip building Boost with stdcxx -- Key: STDCXX-430 URL: https://issues.apache.org/jira/browse/STDCXX-430 Project: C++ Standard Library Issue Type: Improvement Components: External Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Farid Zaripov Priority: Critical Fix For: 4.2.1 Attachments: boost-1.34.1.patch, boost_regress_gcc.zip, boost_regress_sun.zip, boost_regress_win.zip This is a placeholder issue to make it possible and easy to build the Boost libraries on top of stdcxx. Each stdcxx bug revealed by Boost must have an issue. The issue should be linked to this one. Changes contributed to Boost (such as stdcxx .jam files) should be tracked as subtasks of this issue. Each bug in Boost should be filed in the Boost bug tracking database and cross-referenced in comments on this issue. See the following threads for details of the project: http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg02910.html http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03089.html http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03410.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-430) building Boost with stdcxx
[ https://issues.apache.org/jira/browse/STDCXX-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554324 ] Farid Zaripov commented on STDCXX-430: -- Steps for the building boost with stdcxx. 1. build the all build types of the stdcxx with BUILDDIR=%stdcxx_build_dir%/%buildtype% 2. extract the boost sources and apply attached boost-1.34.1.patch 3. build bjam executable by invoking %boostdir%/tools/jam/src/build.sh (build.bat for Windows) and copy the built bjam excutable from %boostdir%/tools/jam/src/bin.linux86 (%boostdir%/tools/jam/src/bin.ntx86 for Windows) to some directory in the path i.e. /usr/local/bin (C:\windows for Windows) 4. edit %boostdir%/tools/build/v2/user-config.jam file to configure the available toolsets and tools and add the line for configuring the stdcxx: using stdcxx : %stdcxx_version% : %stdcxx_root_dir% %stdcxx_build_dir% ; I.e. for linux add the following lines: using gcc ; using python ; using stdcxx : 4.2.0 : /usr/src/stdcxx-4.2.0 /usr/tmp/stdcxx-4.2.0 ; I.e. for windows add the following lines: using msvc ; using python : 2.5 : C:/Python25 ; using stdcxx : 4.2.0 : C:/stdcxx-4.2.0 C:/build/stdcxx-4.2.0 ; 5. build the requested boost libraries by invoking bjam from %boostdir%, i.e.: bjam --v2 --toolset=msvc-7.1 stdlib=stdcxx-4.2.0 variant=release link=static runtime-link=static threading=single address-model=32 stage or bjam --v2 --toolset=gcc stdlib=stdcxx-4.2.0 variant=debug link=shared runtime-link=shared threading=multi address-model=64 stage 6. install the built boost libraries: bjam --v2 --toolset=msvc-7.1 stdlib=stdcxx-4.2.0 variant=release link=static runtime-link=static threading=single address-model=32 install or bjam --v2 --toolset=gcc stdlib=stdcxx-4.2.0 variant=debug link=shared runtime-link=shared threading=multi address-model=64 install building Boost with stdcxx -- Key: STDCXX-430 URL: https://issues.apache.org/jira/browse/STDCXX-430 Project: C++ Standard Library Issue Type: Improvement Components: External Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Farid Zaripov Priority: Critical Fix For: 4.2.1 Attachments: boost-1.34.1.patch This is a placeholder issue to make it possible and easy to build the Boost libraries on top of stdcxx. Each stdcxx bug revealed by Boost must have an issue. The issue should be linked to this one. Changes contributed to Boost (such as stdcxx .jam files) should be tracked as subtasks of this issue. Each bug in Boost should be filed in the Boost bug tracking database and cross-referenced in comments on this issue. See the following threads for details of the project: http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg02910.html http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03089.html http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03410.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-585) [gcc 4.2.0/Cygwin] linker errors due to multiple definition of `std::bad_cast::what()'; `std::bad_typeid::what()'; `std::bad_exception::what()'; `std::bad_alloc::what()'
[ https://issues.apache.org/jira/browse/STDCXX-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-585. -- Resolution: Fixed [gcc 4.2.0/Cygwin] linker errors due to multiple definition of `std::bad_cast::what()'; `std::bad_typeid::what()'; `std::bad_exception::what()'; `std::bad_alloc::what()' - Key: STDCXX-585 URL: https://issues.apache.org/jira/browse/STDCXX-585 Project: C++ Standard Library Issue Type: Bug Components: Configuration Affects Versions: 4.2.0 Environment: gcc 4.2.0 / Cygwin Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Blocker Fix For: 4.2.1 Attachments: BAD_ALLOC_ASSIGNMENT.cpp.diff When building the stdcxx on Cygwin I get errors like: make: Entering directory `/usr/src/stdcxx/trunk/build/examples' gcc -c -I/usr/src/stdcxx/trunk/include/ansi -D_RWSTDDEBUG -D_REENTRANT -mthreads -I/usr/src/stdcxx/trunk/include -I/usr/src/stdcxx/trunk/build/include -I/usr/src/stdcxx/trunk/examples/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align /usr/src/stdcxx/trunk/examples/manual/accumulate.cpp gcc accumulate.o -o accumulate -mthreads -L/usr/src/stdcxx/trunk/build/lib -lstd15s -lsupc++ -lcatgets -liconv -lm /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(tinfo.o): In function `_ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastEiNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16__dyncast_resultE': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/tinfo.cc:418: multiple definition of `std::bad_cast::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(typeinfo.o):/usr/src/stdcxx/trunk/src/typeinfo.cpp:349: first defined here /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(tinfo.o): In function `_ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastEiNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16__dyncast_resultE': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/tinfo.cc:418: multiple definition of `std::bad_typeid::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(typeinfo.o):/usr/src/stdcxx/trunk/src/typeinfo.cpp:414: first defined here /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(new_handler.o): In function `_ZNSt9bad_allocD2Ev': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/new_handler.cc:48: multiple definition of `std::bad_alloc::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(memory.o):/usr/src/stdcxx/trunk/src/memory.cpp:331: first defined here /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(eh_exception.o): In function `_ZNSt13bad_exceptionD2Ev': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/eh_exception.cc:38: multiple definition of `std::bad_exception::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(exception.o):/usr/src/stdcxx/trunk/src/exception.cpp:412: first defined here collect2: ld returned 1 exit status make: *** [accumulate] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-226) __rw::__rw_new_capacity() uses floating point math
[ https://issues.apache.org/jira/browse/STDCXX-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553368 ] Farid Zaripov commented on STDCXX-226: -- In the committed patch the _RWSTD_NEW_CAPACITY_RATIO and _RWSTD_STRING_CAPACITY_RATIO floating point values replaced to integer (multiplied with _RWSTD_RATIO_DIVIDER == 1000). __rw::__rw_new_capacity() uses floating point math -- Key: STDCXX-226 URL: https://issues.apache.org/jira/browse/STDCXX-226 Project: C++ Standard Library Issue Type: Improvement Components: 23. Containers Affects Versions: 4.1.2, 4.1.3, 4.2.0 Environment: all Reporter: Martin Sebor Assignee: Farid Zaripov Fix For: 4.2.1 Attachments: benchmark-stdcxx-226.c, new_capacity.patch Moved from the Rogue Wave bug tracking database: Created By: sebor @ May 09, 2002 11:15:41 AM The template __rw_new_capacity() uses floating point arithmetic which may be less efficient than integer arithmetic on some architectures. Need to change to integer arithmetic and correctly handle integer overflow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-226) __rw::__rw_new_capacity() uses floating point math
[ https://issues.apache.org/jira/browse/STDCXX-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-226. -- Resolution: Fixed Resolved thus: http://svn.apache.org/viewvc?rev=605548view=rev __rw::__rw_new_capacity() uses floating point math -- Key: STDCXX-226 URL: https://issues.apache.org/jira/browse/STDCXX-226 Project: C++ Standard Library Issue Type: Improvement Components: 23. Containers Affects Versions: 4.1.2, 4.1.3, 4.2.0 Environment: all Reporter: Martin Sebor Assignee: Farid Zaripov Fix For: 4.2.1 Attachments: benchmark-stdcxx-226.c, new_capacity.patch Moved from the Rogue Wave bug tracking database: Created By: sebor @ May 09, 2002 11:15:41 AM The template __rw_new_capacity() uses floating point arithmetic which may be less efficient than integer arithmetic on some architectures. Need to change to integer arithmetic and correctly handle integer overflow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-666) [MSVC 8-x64] 21.string.cons.cpp test fails in optimized builds due to bad codegeneration by the compiler
[
https://issues.apache.org/jira/browse/STDCXX-666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov resolved STDCXX-666.
--
Resolution: Fixed
The issue resolved thus resolving the STDCXX-226.
[MSVC 8-x64] 21.string.cons.cpp test fails in optimized builds due to bad
codegeneration by the compiler
Key: STDCXX-666
URL: https://issues.apache.org/jira/browse/STDCXX-666
Project: C++ Standard Library
Issue Type: Bug
Components: Tests
Affects Versions: 4.2.0
Environment: MSVC 8.0-x64, builds 8{d|s}, 12{d|s}
Reporter: Farid Zaripov
Assignee: Farid Zaripov
Fix For: 4.2.1
The 21.string.cons.cpp test fails with 16 assertions on 64-bit MSVC in
optimized builds.
The reason is the bad codegeneration in __rw_new_capacity() inlined in
std::basic_string ctors. Because of this bug the __rw_new_capacity(0, const
std::basic_string *) returns value greater that size_max() and ctor throws
exception.
The temporary workaround might be definition of the __rw_new_capacity() as
__declspec (noinline).
--
Index: include/string
===
--- include/string(revision 593511)
+++ include/string(working copy)
@@ -1528,8 +1528,13 @@
// more specialized version for basic_string; may be further specialized
// in user code for example on a user-defined allocator
+#if !defined (_WIN64) || !defined (_MSC_VER) || defined
(__INTEL_COMPILER)
template class _CharT, class _Traits, class _Allocator inline
_RWSTD_STRING_SIZE_TYPE
+#else// _WIN64 _MSC_VER !__INTEL_COMPILER
+template class _CharT, class _Traits, class _Allocator __declspec
+(noinline) _RWSTD_STRING_SIZE_TYPE
+#endif // !_WIN64 || !_MSC_VER || __INTEL_COMPILER
__rw_new_capacity (_RWSTD_STRING_SIZE_TYPE __size,
const _STD::basic_string_CharT, _Traits,
_Allocator*)
{
--
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-250) std::operator(istream, string) fails to set failbit after it extracts 0 characters
[
https://issues.apache.org/jira/browse/STDCXX-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-250:
-
Component/s: (was: 27. Input/Output)
21. Strings
Component changed to 21.strings (the opertator(istream, string) is related
to 21.string.io part of the standard).
std::operator(istream, string) fails to set failbit after it extracts 0
characters
--
Key: STDCXX-250
URL: https://issues.apache.org/jira/browse/STDCXX-250
Project: C++ Standard Library
Issue Type: Bug
Components: 21. Strings
Affects Versions: 4.1.2, 4.1.3
Environment: all
Reporter: Martin Sebor
Assignee: Farid Zaripov
Priority: Minor
Fix For: 4.2.1
Attachments: istream.cc.diff
21.3.7.9, p3 says about the string extractor: If the function extracts no
characters, it calls is.setstate(ios::failbit), which may throw
ios_base::failure (27.4.4.3). The test program below shows that in
unbuffered mode stdcxx fails to do so when an exception is thrown during the
third call to underflow().
$ cat v.cpp make v ./v
#include cassert
#include cstdio
#include istream
#include string
int main ()
{
struct: std::streambuf {
int_type underflow () {
static int i = 0;
// i == 0: sgect() invoked from sentry ctor
// i == 1: sgetc() invoked from operator()
// i == 2: sbumpc() invoked from operator()
return 1 i++ ? throw i : 'x';
}
} buf;
std::istream is (buf);
std::string s;
is s;
std::printf (state = %c%c%c, string = \%s\ (length %u)\n,
is.rdstate () is.badbit ? 'B' : '-',
is.rdstate () is.eofbit ? 'E' : '-',
is.rdstate () is.failbit ? 'F' : '-',
s.c_str (), s.size ());
assert (x == s);
assert ((is.failbit | is.badbit) == is.rdstate ());
}
gcc -c -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG -pthreads
-D_RWSTD_USE_CONFIG -I/build/sebor/dev/stdlib/include
-I/build/sebor/gcc-4.1.0-15s/include -I/build/sebor/dev/stdlib/../rwtest
-I/build/sebor/dev/stdlib/../rwtest/include
-I/build/sebor/dev/stdlib/tests/include -pedantic -nostdinc++ -g -W -Wall
-Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long v.cpp
gcc v.o -o v -L/build/sebor/gcc-4.1.0-15s/rwtest -lrwtest15s -pthreads
-L/build/sebor/gcc-4.1.0-15s/lib -lstd15s -lsupc++ -lm
state = B--, string = x (length 1)
Assertion failed: (is.failbit | is.badbit) == is.rdstate (), file v.cpp, line
30
Abort (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-250) std::operator(istream, string) fails to set failbit after it extracts 0 characters
[
https://issues.apache.org/jira/browse/STDCXX-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov resolved STDCXX-250.
--
Resolution: Fixed
Resolved thus: http://svn.apache.org/viewvc?rev=605577view=rev
The regression test added thus: http://svn.apache.org/viewvc?rev=605586view=rev
std::operator(istream, string) fails to set failbit after it extracts 0
characters
--
Key: STDCXX-250
URL: https://issues.apache.org/jira/browse/STDCXX-250
Project: C++ Standard Library
Issue Type: Bug
Components: 21. Strings
Affects Versions: 4.1.2, 4.1.3
Environment: all
Reporter: Martin Sebor
Assignee: Farid Zaripov
Priority: Minor
Fix For: 4.2.1
Attachments: istream.cc.diff
21.3.7.9, p3 says about the string extractor: If the function extracts no
characters, it calls is.setstate(ios::failbit), which may throw
ios_base::failure (27.4.4.3). The test program below shows that in
unbuffered mode stdcxx fails to do so when an exception is thrown during the
third call to underflow().
$ cat v.cpp make v ./v
#include cassert
#include cstdio
#include istream
#include string
int main ()
{
struct: std::streambuf {
int_type underflow () {
static int i = 0;
// i == 0: sgect() invoked from sentry ctor
// i == 1: sgetc() invoked from operator()
// i == 2: sbumpc() invoked from operator()
return 1 i++ ? throw i : 'x';
}
} buf;
std::istream is (buf);
std::string s;
is s;
std::printf (state = %c%c%c, string = \%s\ (length %u)\n,
is.rdstate () is.badbit ? 'B' : '-',
is.rdstate () is.eofbit ? 'E' : '-',
is.rdstate () is.failbit ? 'F' : '-',
s.c_str (), s.size ());
assert (x == s);
assert ((is.failbit | is.badbit) == is.rdstate ());
}
gcc -c -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG -pthreads
-D_RWSTD_USE_CONFIG -I/build/sebor/dev/stdlib/include
-I/build/sebor/gcc-4.1.0-15s/include -I/build/sebor/dev/stdlib/../rwtest
-I/build/sebor/dev/stdlib/../rwtest/include
-I/build/sebor/dev/stdlib/tests/include -pedantic -nostdinc++ -g -W -Wall
-Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long v.cpp
gcc v.o -o v -L/build/sebor/gcc-4.1.0-15s/rwtest -lrwtest15s -pthreads
-L/build/sebor/gcc-4.1.0-15s/lib -lstd15s -lsupc++ -lm
state = B--, string = x (length 1)
Assertion failed: (is.failbit | is.badbit) == is.rdstate (), file v.cpp, line
30
Abort (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-408) make use of __declspec(dll{export,import}) on all platforms
[
https://issues.apache.org/jira/browse/STDCXX-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-408:
-
Patch Info: [Patch Available]
make use of __declspec(dll{export,import}) on all platforms
---
Key: STDCXX-408
URL: https://issues.apache.org/jira/browse/STDCXX-408
Project: C++ Standard Library
Issue Type: Improvement
Components: Build
Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0
Environment: HP aCC 3.37 and beyond, gcc/Linux
Reporter: Martin Sebor
Assignee: Farid Zaripov
Fix For: 4.2.1
Attachments: dllexport.patch
Starting with HP aCC 3.37 the compiler supports the __declspec(dllexport) and
__declspec(dllimport) decorators on declarations of symbols with external
linkage. According to the Release Notes for the compiler, Support of these
keywords enhances the performance of shared libraries and relieves the usage
of HP_DEFINED_EXTERNAL pragmas and +Oextern= list to hide the non-exported
symbols. See http://docs.hp.com/en/2212/A-03-37relnotes.html.
We should enable this in our builds.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-408) make use of __declspec(dll{export,import}) on all platforms
[
https://issues.apache.org/jira/browse/STDCXX-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-408:
-
Attachment: gmake.log
The gmake.log file is attached.
make use of __declspec(dll{export,import}) on all platforms
---
Key: STDCXX-408
URL: https://issues.apache.org/jira/browse/STDCXX-408
Project: C++ Standard Library
Issue Type: Improvement
Components: Build
Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0
Environment: HP aCC 3.37 and beyond, gcc/Linux
Reporter: Martin Sebor
Assignee: Farid Zaripov
Fix For: 4.2.1
Attachments: dllexport.patch, gmake.log
Starting with HP aCC 3.37 the compiler supports the __declspec(dllexport) and
__declspec(dllimport) decorators on declarations of symbols with external
linkage. According to the Release Notes for the compiler, Support of these
keywords enhances the performance of shared libraries and relieves the usage
of HP_DEFINED_EXTERNAL pragmas and +Oextern= list to hide the non-exported
symbols. See http://docs.hp.com/en/2212/A-03-37relnotes.html.
We should enable this in our builds.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-610) [Windows] add version information to the library
[ https://issues.apache.org/jira/browse/STDCXX-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov reassigned STDCXX-610: Assignee: Farid Zaripov [Windows] add version information to the library Key: STDCXX-610 URL: https://issues.apache.org/jira/browse/STDCXX-610 Project: C++ Standard Library Issue Type: New Feature Components: Build Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 Environment: MSVC and Intel C++ on Windows Reporter: Martin Sebor Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 From the thread starting at http://www.nabble.com/-VERSION-linker-option-on-Windows-tf4650202.html: Original Message Subject: Re: /VERSION linker option on Windows Date: Thu, 18 Oct 2007 18:20:09 -0500 From: William A. Rowe, Jr. [EMAIL PROTECTED] Reply-To: stdcxx-dev@incubator.apache.org To: stdcxx-dev@incubator.apache.org References: [EMAIL PROTECTED] Martin Sebor wrote: Are we making use of it? If not, should we be? http://msdn2.microsoft.com/en-us/library/h88b7dc8(VS.80).aspx It's not terribly interesting. You really want to focus on the VERSIONINFO member of the library's dll resource, which provides a whole lot more meaningful information to the user/developer. I presume you already attach that? Bill -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-610) [Windows] add version information to the library
[ https://issues.apache.org/jira/browse/STDCXX-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-610: - Attachment: libstd.rc The draft of the libstd.rc is attached. [Windows] add version information to the library Key: STDCXX-610 URL: https://issues.apache.org/jira/browse/STDCXX-610 Project: C++ Standard Library Issue Type: New Feature Components: Build Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 Environment: MSVC and Intel C++ on Windows Reporter: Martin Sebor Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 Attachments: libstd.rc From the thread starting at http://www.nabble.com/-VERSION-linker-option-on-Windows-tf4650202.html: Original Message Subject: Re: /VERSION linker option on Windows Date: Thu, 18 Oct 2007 18:20:09 -0500 From: William A. Rowe, Jr. [EMAIL PROTECTED] Reply-To: stdcxx-dev@incubator.apache.org To: stdcxx-dev@incubator.apache.org References: [EMAIL PROTECTED] Martin Sebor wrote: Are we making use of it? If not, should we be? http://msdn2.microsoft.com/en-us/library/h88b7dc8(VS.80).aspx It's not terribly interesting. You really want to focus on the VERSIONINFO member of the library's dll resource, which provides a whole lot more meaningful information to the user/developer. I presume you already attach that? Bill -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-675) [MSVC] implement autolinking feature
[ https://issues.apache.org/jira/browse/STDCXX-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552841 ] Farid Zaripov commented on STDCXX-675: -- Yes. This change doesn't affect the exported symbols or anything else. It's only add's the record in object files, compiled with using this change, to link these object files with libstdxx.lib. [MSVC] implement autolinking feature Key: STDCXX-675 URL: https://issues.apache.org/jira/browse/STDCXX-675 Project: C++ Standard Library Issue Type: Improvement Components: Configuration Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 Environment: MSVC, ICC/Windows Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Trivial Fix For: 4.2.1 Attachments: autolink.patch At the moment the users of the library should explicitly specify the used library name in linker command line. Here might be problems if the user's project was compiled with config.h for some configuration (let's say 12d) but linked with library for another configuration (i.e. libstd12s.lib). The MSVC and ICC/Windows has the posibility to specify the library using #pragma comment (lib, libname) directive. So #including any header from the library will leads to linking automatically with the proper library file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-459) time_get::date_order() should return actually date order taken from locale
[ https://issues.apache.org/jira/browse/STDCXX-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552871 ] Farid Zaripov commented on STDCXX-459: -- 1. This change is not necessary (and even more, it's incorrect, because __rw_get_timepunct() should be exported if the user instantiates the std::time_getuser_char, user_iterator). 2. The __rw_get_dateorder() should also be _RWSTD_EXPORT to be accessible from std::time_getuser_char, user_iterator. And this change is not a forward binary compatible. 3. I think yes. The outlining doesn't add's the new symbol in the library. The only what may change - it's a return value from the date_order(). But since the all possible returning values are valid (the user of the library shouldn't rely on the always returned no_order from date_order()) this change is safe. time_get::date_order() should return actually date order taken from locale -- Key: STDCXX-459 URL: https://issues.apache.org/jira/browse/STDCXX-459 Project: C++ Standard Library Issue Type: Improvement Components: 22. Localization Affects Versions: 4.1.2, 4.1.3, 4.1.4 Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 Attachments: stdcxx-459.patch The current implementation of the time_get::date_order() always returns no_order. It should return date order used by a locale facet (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03734.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-226) __rw::__rw_new_capacity() uses floating point math
[ https://issues.apache.org/jira/browse/STDCXX-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551505 ] Farid Zaripov commented on STDCXX-226: -- In my patch _RWSTD_NEW_CAPACITY_RATIO still double, and it's converted to an integer in __rw_new_capacity: --- const _RWSizeT __ratio = _RWSizeT (_RWSTD_NEW_CAPACITY_RATIO * 1024); --- Since here _RWSTD_NEW_CAPACITY_RATIO and 1024 are constants, the compiler should calculate __ratio in compile time. __rw::__rw_new_capacity() uses floating point math -- Key: STDCXX-226 URL: https://issues.apache.org/jira/browse/STDCXX-226 Project: C++ Standard Library Issue Type: Improvement Components: 23. Containers Affects Versions: 4.1.2, 4.1.3, 4.2.0 Environment: all Reporter: Martin Sebor Assignee: Farid Zaripov Fix For: 4.2.1 Attachments: benchmark-stdcxx-226.c, new_capacity.patch Moved from the Rogue Wave bug tracking database: Created By: sebor @ May 09, 2002 11:15:41 AM The template __rw_new_capacity() uses floating point arithmetic which may be less efficient than integer arithmetic on some architectures. Need to change to integer arithmetic and correctly handle integer overflow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-226) __rw::__rw_new_capacity() uses floating point math
[
https://issues.apache.org/jira/browse/STDCXX-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551006
]
Farid Zaripov commented on STDCXX-226:
--
In my testing the algorithm in My patch is more accurate :)
--
unsigned long f2 (unsigned long x)
{
unsigned long z = (x 10) * 1000 + (((x 0x3ff) * 1000) 10);
return z;
}
--
Here instead of 1000 should be ratio * 1024 == 1,618L * 1024 == 1656.
Also in My algorithm the 1.618 ratio is present explicitly and can be changed
to any other value when it's needed.
__rw::__rw_new_capacity() uses floating point math
--
Key: STDCXX-226
URL: https://issues.apache.org/jira/browse/STDCXX-226
Project: C++ Standard Library
Issue Type: Improvement
Components: 23. Containers
Affects Versions: 4.1.2, 4.1.3, 4.2.0
Environment: all
Reporter: Martin Sebor
Assignee: Farid Zaripov
Fix For: 4.2.1
Attachments: benchmark-stdcxx-226.c, new_capacity.patch
Moved from the Rogue Wave bug tracking database:
Created By: sebor @ May 09, 2002 11:15:41 AM
The template __rw_new_capacity() uses floating point arithmetic which may be
less efficient than integer arithmetic on some architectures. Need to change
to integer arithmetic and correctly handle integer overflow.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-226) __rw::__rw_new_capacity() uses floating point math
[ https://issues.apache.org/jira/browse/STDCXX-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-226: - Severity: Inefficiency Patch Info: [Patch Available] Affects Version/s: 4.2.0 Fix Version/s: 4.2.1 __rw::__rw_new_capacity() uses floating point math -- Key: STDCXX-226 URL: https://issues.apache.org/jira/browse/STDCXX-226 Project: C++ Standard Library Issue Type: Improvement Components: 23. Containers Affects Versions: 4.1.2, 4.1.3, 4.2.0 Environment: all Reporter: Martin Sebor Assignee: Farid Zaripov Fix For: 4.2.1 Attachments: new_capacity.patch Moved from the Rogue Wave bug tracking database: Created By: sebor @ May 09, 2002 11:15:41 AM The template __rw_new_capacity() uses floating point arithmetic which may be less efficient than integer arithmetic on some architectures. Need to change to integer arithmetic and correctly handle integer overflow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-408) make use of __declspec(dll{export,import}) on all platforms
[
https://issues.apache.org/jira/browse/STDCXX-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549772
]
Farid Zaripov commented on STDCXX-408:
--
The gcc implements dllexport/dllimport attributes only on Windows and Symbian
target platforms (i.e. Cygwin)..
make use of __declspec(dll{export,import}) on all platforms
---
Key: STDCXX-408
URL: https://issues.apache.org/jira/browse/STDCXX-408
Project: C++ Standard Library
Issue Type: Improvement
Components: Build
Affects Versions: 4.1.3
Environment: HP aCC 3.37 and beyond, gcc/Linux
Reporter: Martin Sebor
Fix For: 4.2.1
Starting with HP aCC 3.37 the compiler supports the __declspec(dllexport) and
__declspec(dllimport) decorators on declarations of symbols with external
linkage. According to the Release Notes for the compiler, Support of these
keywords enhances the performance of shared libraries and relieves the usage
of HP_DEFINED_EXTERNAL pragmas and +Oextern= list to hide the non-exported
symbols. See http://docs.hp.com/en/2212/A-03-37relnotes.html.
We should enable this in our builds.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-507) [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds
[ https://issues.apache.org/jira/browse/STDCXX-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-507: - Attachment: cygwin.patch The patch is attached. [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds --- Key: STDCXX-507 URL: https://issues.apache.org/jira/browse/STDCXX-507 Project: C++ Standard Library Issue Type: Bug Components: Build Affects Versions: 4.2.0 Environment: gcc 3.4.4/Cygwin Reporter: Farid Zaripov Assignee: Farid Zaripov Fix For: 4.2.1 Attachments: cygwin.patch, localedef.imports Many utilities, examples and tests failed to start due to access violation while loading libstdxxx.dll. In night builds logs they all finished with status 5. The reason is access violation while loading libstdxxx.dll. All of them has many times duplicated imports (see the attached file) and I suppose that bug in ld utility. $ ./localedef || echo $? 5 $ strace /usr/src/stdcxx/trunk/build15d/bin/localedef --- Process 732, exception C005 at 7C919994 --- Process 732, exception C005 at 7C964ED1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-507) [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds
[ https://issues.apache.org/jira/browse/STDCXX-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-507: - Attachment: (was: cygwin.patch) [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds --- Key: STDCXX-507 URL: https://issues.apache.org/jira/browse/STDCXX-507 Project: C++ Standard Library Issue Type: Bug Components: Build Affects Versions: 4.2.0 Environment: gcc 3.4.4/Cygwin Reporter: Farid Zaripov Assignee: Farid Zaripov Fix For: 4.2.1 Attachments: cygwin.patch, localedef.imports Many utilities, examples and tests failed to start due to access violation while loading libstdxxx.dll. In night builds logs they all finished with status 5. The reason is access violation while loading libstdxxx.dll. All of them has many times duplicated imports (see the attached file) and I suppose that bug in ld utility. $ ./localedef || echo $? 5 $ strace /usr/src/stdcxx/trunk/build15d/bin/localedef --- Process 732, exception C005 at 7C919994 --- Process 732, exception C005 at 7C964ED1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-507) [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds
[ https://issues.apache.org/jira/browse/STDCXX-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-507: - Patch Info: [Patch Available] [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds --- Key: STDCXX-507 URL: https://issues.apache.org/jira/browse/STDCXX-507 Project: C++ Standard Library Issue Type: Bug Components: Build Affects Versions: 4.2.0 Environment: gcc 3.4.4/Cygwin Reporter: Farid Zaripov Assignee: Farid Zaripov Fix For: 4.2.1 Attachments: cygwin.patch, localedef.imports Many utilities, examples and tests failed to start due to access violation while loading libstdxxx.dll. In night builds logs they all finished with status 5. The reason is access violation while loading libstdxxx.dll. All of them has many times duplicated imports (see the attached file) and I suppose that bug in ld utility. $ ./localedef || echo $? 5 $ strace /usr/src/stdcxx/trunk/build15d/bin/localedef --- Process 732, exception C005 at 7C919994 --- Process 732, exception C005 at 7C964ED1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-507) [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds
[ https://issues.apache.org/jira/browse/STDCXX-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549499 ] Farid Zaripov commented on STDCXX-507: -- After the patch the examples and tests are built successfully. But there left some problems when running (exit code == 128): The failed examples: NAME STATUS WARN ASSERTS FAILED PERCNTUSER SYSREAL alg1 1280 0.000 0.015 0.123 complex 1280 0.015 0.015 0.445 complx1280 0.000 0.015 0.126 filebuf 1280 0.000 0.015 0.073 fstream 1280 0.000 0.015 0.089 ifstream 1280 0.000 0.015 0.087 insert_wchar 1280 0.000 0.015 0.077 istream1 1280 0.000 0.000 0.071 istreambuf_iterator 1280 0.000 0.015 0.084 istringstream 1280 0.000 0.015 0.075 istrstream1280 0.000 0.046 0.077 money_get 1280 0.000 0.015 0.061 multiset 1280 0.000 0.046 0.143 num_get 1280 0.000 0.031 0.068 num_put 1280 0.000 0.015 0.122 ostream 1280 0.000 0.015 0.111 setex 1280 0.000 0.046 0.135 spell 1280 0.000 0.015 0.109 stringbuf 1280 0.015 0.046 0.070 strstream 1280 0.015 0.015 0.108 strstreambuf 1280 0.015 0.031 0.079 time_get 1280 0.000 0.015 0.088 time_put 1280 0.000 0.015 0.277 wostream 1280 0.000 0.015 0.106 wstringstream 1280 0.000 0.015 0.090 The failed tests: NAME STATUS WARN ASSERTS FAILED PERCNTUSER SYSREAL 21.string.io 1280 0.000 0.015 0.134 21.string.io.stdcxx-206 1280 0.000 0.000 0.091 22.locale.globals.mt 1280 0.000 0.015 0.090 22.locale.messages1280 0.000 0.015 0.101 22.locale.money.get.mt1280 0.000 0.015 0.104 22.locale.money.get 1280 0.000 0.062 0.102 22.locale.money.put.mt1280 0.000 0.015 0.100 22.locale.money.put 1280 0.000 0.015 0.127 22.locale.moneypunct 1280 0.000 0.031 0.107 22.locale.num.get.mt 1280 0.000 0.015 0.107 22.locale.num.get 1280 0.000 0.015 0.115 22.locale.num.put.mt 1280 0.000 0.031 0.101 22.locale.num.put 1280 0.015 0.031 0.133 22.locale.time.get.mt 1280 0.000 0.015 0.102 22.locale.time.get1280 0.000 0.015 0.104 22.locale.time.put.mt 1280 0.000 0.000 0.127 22.locale.time.put1280 0.000 0.031 0.103 27.filebuf.codecvt1280 0.000 0.031 0.087 27.filebuf.virtuals.stdcxx-5221280 0.000 0.015 0.089 27.istream.fmat.arith 1280 0.000 0.015 0.097 27.istream.manip 1280 0.000 0.015 0.109 27.istream.readsome 1280 0.000 0.015 0.098 27.istream.sentry 1280 0.000 0.015 0.099 27.ostream1280 0.000 0.015 0.105
[jira] Resolved: (STDCXX-663) [MSVC] MSVC declares non-standard prototype of the wcstok()
[ https://issues.apache.org/jira/browse/STDCXX-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-663. -- Resolution: Fixed Fixed thus: http://svn.apache.org/viewvc?view=revrevision=597411 Merged in thunk thus: http://svn.apache.org/viewvc?view=revrevision=597412 [MSVC] MSVC declares non-standard prototype of the wcstok() --- Key: STDCXX-663 URL: https://issues.apache.org/jira/browse/STDCXX-663 Project: C++ Standard Library Issue Type: Bug Components: External Environment: MSVC, ICC/Windows Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 Attachments: wcstok.patch The MSVC declares non-standard prototype of the wcstok(): wchar.h: --- _CRTIMP wchar_t * __cdecl wcstok(wchar_t *, const wchar_t *); --- Since configuration script doesn't check the correct prototype and checks only for name, the config.h file contains _RWSTD_NO_WCSTOK macro undefined. The MSVC 8 and higher declares wcstok_s() which is identical to standard wcstok(): wchar.h: --- _CRTIMP_ALTERNATIVE __checkReturn wchar_t * __cdecl wcstok_s(__inout_z_opt wchar_t * _Str, __in_z const wchar_t * _Delim, __deref_inout_z_opt wchar_t ** _Context); --- I think we need to #define _RWSTD_NO_WCSTOK macro in include/rw/_config_msvcrt.h and add inline wcstok() invoking wcstok_s() in include /ansi/cwchar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-666) [MSVC 8-x64] 21.string.cons.cpp test fails in optimized builds due to bad codegeneration by the compiler
[
https://issues.apache.org/jira/browse/STDCXX-666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov reassigned STDCXX-666:
Assignee: Farid Zaripov
[MSVC 8-x64] 21.string.cons.cpp test fails in optimized builds due to bad
codegeneration by the compiler
Key: STDCXX-666
URL: https://issues.apache.org/jira/browse/STDCXX-666
Project: C++ Standard Library
Issue Type: Bug
Components: Tests
Affects Versions: 4.2.0
Environment: MSVC 8.0-x64, builds 8{d|s}, 12{d|s}
Reporter: Farid Zaripov
Assignee: Farid Zaripov
Fix For: 4.2.1
The 21.string.cons.cpp test fails with 16 assertions on 64-bit MSVC in
optimized builds.
The reason is the bad codegeneration in __rw_new_capacity() inlined in
std::basic_string ctors. Because of this bug the __rw_new_capacity(0, const
std::basic_string *) returns value greater that size_max() and ctor throws
exception.
The temporary workaround might be definition of the __rw_new_capacity() as
__declspec (noinline).
--
Index: include/string
===
--- include/string(revision 593511)
+++ include/string(working copy)
@@ -1528,8 +1528,13 @@
// more specialized version for basic_string; may be further specialized
// in user code for example on a user-defined allocator
+#if !defined (_WIN64) || !defined (_MSC_VER) || defined
(__INTEL_COMPILER)
template class _CharT, class _Traits, class _Allocator inline
_RWSTD_STRING_SIZE_TYPE
+#else// _WIN64 _MSC_VER !__INTEL_COMPILER
+template class _CharT, class _Traits, class _Allocator __declspec
+(noinline) _RWSTD_STRING_SIZE_TYPE
+#endif // !_WIN64 || !_MSC_VER || __INTEL_COMPILER
__rw_new_capacity (_RWSTD_STRING_SIZE_TYPE __size,
const _STD::basic_string_CharT, _Traits,
_Allocator*)
{
--
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-675) [MSVC] implement autolinking feature
[ https://issues.apache.org/jira/browse/STDCXX-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-675: - Attachment: autolink.patch [MSVC] implement autolinking feature Key: STDCXX-675 URL: https://issues.apache.org/jira/browse/STDCXX-675 Project: C++ Standard Library Issue Type: Improvement Components: Configuration Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 Environment: MSVC, ICC/Windows Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Trivial Fix For: 4.2.1 Attachments: autolink.patch At the moment the users of the library should explicitly specify the used library name in linker command line. Here might be problems if the user's project was compiled with config.h for some configuration (let's say 12d) but linked with library for another configuration (i.e. libstd12s.lib). The MSVC and ICC/Windows has the posibility to specify the library using #pragma comment (lib, libname) directive. So #including any header from the library will leads to linking automatically with the proper library file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-675) [MSVC] implement autolinking feature
[ https://issues.apache.org/jira/browse/STDCXX-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547221 ] Farid Zaripov commented on STDCXX-675: -- ChangeLog: STDCXX-675 * include/rw/_autolink.h: New header file to enable autolinking feature. * include/rw/_config-msvcrt.h: #include _autolink.h. * src/export.cpp: Added missing #define _RWSTD_LIB_SRC macro. The _autolink.h file is intended to be #included in _config.h, but since this feature is supported by only MSVC and ICC/Windows, it #included in _config-msvcrt.h. [MSVC] implement autolinking feature Key: STDCXX-675 URL: https://issues.apache.org/jira/browse/STDCXX-675 Project: C++ Standard Library Issue Type: Improvement Components: Configuration Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 Environment: MSVC, ICC/Windows Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Trivial Fix For: 4.2.1 Attachments: autolink.patch At the moment the users of the library should explicitly specify the used library name in linker command line. Here might be problems if the user's project was compiled with config.h for some configuration (let's say 12d) but linked with library for another configuration (i.e. libstd12s.lib). The MSVC and ICC/Windows has the posibility to specify the library using #pragma comment (lib, libname) directive. So #including any header from the library will leads to linking automatically with the proper library file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-459) time_get::date_order() should return actually date order taken from locale
[ https://issues.apache.org/jira/browse/STDCXX-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov reassigned STDCXX-459: Assignee: Farid Zaripov time_get::date_order() should return actually date order taken from locale -- Key: STDCXX-459 URL: https://issues.apache.org/jira/browse/STDCXX-459 Project: C++ Standard Library Issue Type: Improvement Components: 22. Localization Affects Versions: 4.1.2, 4.1.3, 4.1.4 Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 The current implementation of the time_get::date_order() always returns no_order. It should return date order used by a locale facet (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03734.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-459) time_get::date_order() should return actually date order taken from locale
[ https://issues.apache.org/jira/browse/STDCXX-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-459: - Attachment: stdcxx-459.patch The proposed patch attached. time_get::date_order() should return actually date order taken from locale -- Key: STDCXX-459 URL: https://issues.apache.org/jira/browse/STDCXX-459 Project: C++ Standard Library Issue Type: Improvement Components: 22. Localization Affects Versions: 4.1.2, 4.1.3, 4.1.4 Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 Attachments: stdcxx-459.patch The current implementation of the time_get::date_order() always returns no_order. It should return date order used by a locale facet (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03734.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-459) time_get::date_order() should return actually date order taken from locale
[ https://issues.apache.org/jira/browse/STDCXX-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-459: - Patch Info: [Patch Available] time_get::date_order() should return actually date order taken from locale -- Key: STDCXX-459 URL: https://issues.apache.org/jira/browse/STDCXX-459 Project: C++ Standard Library Issue Type: Improvement Components: 22. Localization Affects Versions: 4.1.2, 4.1.3, 4.1.4 Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 Attachments: stdcxx-459.patch The current implementation of the time_get::date_order() always returns no_order. It should return date order used by a locale facet (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03734.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-459) time_get::date_order() should return actually date order taken from locale
[ https://issues.apache.org/jira/browse/STDCXX-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546778 ] Farid Zaripov commented on STDCXX-459: -- Another option might be extend the struct __rw_time_t with d_order_off field and determine the dateorder value (or two values for narrow and wide characters) in __rw::__rw_get_timepunct(). time_get::date_order() should return actually date order taken from locale -- Key: STDCXX-459 URL: https://issues.apache.org/jira/browse/STDCXX-459 Project: C++ Standard Library Issue Type: Improvement Components: 22. Localization Affects Versions: 4.1.2, 4.1.3, 4.1.4 Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 Attachments: stdcxx-459.patch The current implementation of the time_get::date_order() always returns no_order. It should return date order used by a locale facet (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03734.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-675) [MSVC] implement autolinking feature
[MSVC] implement autolinking feature Key: STDCXX-675 URL: https://issues.apache.org/jira/browse/STDCXX-675 Project: C++ Standard Library Issue Type: Improvement Components: Configuration Affects Versions: 4.2.0, 4.1.4, 4.1.3, 4.1.2 Environment: MSVC, ICC/Windows Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Trivial Fix For: 4.2.1 At the moment the users of the library should explicitly specify the used library name in linker command line. Here might be problems if the user's project was compiled with config.h for some configuration (let's say 12d) but linked with library for another configuration (i.e. libstd12s.lib). The MSVC and ICC/Windows has the posibility to specify the library using #pragma comment (lib, libname) directive. So #including any header from the library will leads to linking automatically with the proper library file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-675) [MSVC] implement autolinking feature
[ https://issues.apache.org/jira/browse/STDCXX-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546826 ] Farid Zaripov commented on STDCXX-675: -- Perhaps the another compilers may has the similar feature. [MSVC] implement autolinking feature Key: STDCXX-675 URL: https://issues.apache.org/jira/browse/STDCXX-675 Project: C++ Standard Library Issue Type: Improvement Components: Configuration Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 Environment: MSVC, ICC/Windows Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Trivial Fix For: 4.2.1 At the moment the users of the library should explicitly specify the used library name in linker command line. Here might be problems if the user's project was compiled with config.h for some configuration (let's say 12d) but linked with library for another configuration (i.e. libstd12s.lib). The MSVC and ICC/Windows has the posibility to specify the library using #pragma comment (lib, libname) directive. So #including any header from the library will leads to linking automatically with the proper library file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-672) implement C++ 0x Concepts
[ https://issues.apache.org/jira/browse/STDCXX-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-672: - Description: This is a placeholder to [conditionally] implement C++ 0x Concepts in the library and enable them as compilers start to come online (initially for ConceptGCC: http://www.generic-programming.org/software/ConceptGCC ). Normative info on Concepts can be found here: Proposed Wording for Concepts (Revision 3) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2421.pdf Concepts for the C++0x Standard Library: Approach http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2036.pdf Concepts for the C++0x Standard Library: Introduction http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2037.pdf Concepts for the C++0x Standard Library: Algorithms http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2040.pdf Concepts for the C++0x Standard Library: Numerics http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2041.pdf Concepts for the C++0x Standard Library: Utilities (Revision 2): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2322.pdf Concepts for the C++0x Standard Library: Iterators (Revision 2): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2323.pdf was: This is a placeholder to [conditionally] implement C++ 0x Concepts in the library and enable them as compilers start to come online (initially for ConceptGCC: http://www.generic-programming.org/software/ConceptGCC). Normative info on Concepts can be found here: Proposed Wording for Concepts (Revision 3) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2421.pdf Concepts for the C++0x Standard Library: Approach http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2036.pdf Concepts for the C++0x Standard Library: Introduction http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2037.pdf Concepts for the C++0x Standard Library: Algorithms http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2040.pdf Concepts for the C++0x Standard Library: Numerics http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2041.pdf Concepts for the C++0x Standard Library: Utilities (Revision 2): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2322.pdf Concepts for the C++0x Standard Library: Iterators (Revision 2): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2323.pdf Added space between link and the closing round bracket (otherwise this bracket was appended to the link). implement C++ 0x Concepts - Key: STDCXX-672 URL: https://issues.apache.org/jira/browse/STDCXX-672 Project: C++ Standard Library Issue Type: New Feature Components: Configuration Affects Versions: 4.2.0 Reporter: Martin Sebor Fix For: 4.3 This is a placeholder to [conditionally] implement C++ 0x Concepts in the library and enable them as compilers start to come online (initially for ConceptGCC: http://www.generic-programming.org/software/ConceptGCC ). Normative info on Concepts can be found here: Proposed Wording for Concepts (Revision 3) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2421.pdf Concepts for the C++0x Standard Library: Approach http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2036.pdf Concepts for the C++0x Standard Library: Introduction http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2037.pdf Concepts for the C++0x Standard Library: Algorithms http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2040.pdf Concepts for the C++0x Standard Library: Numerics http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2041.pdf Concepts for the C++0x Standard Library: Utilities (Revision 2): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2322.pdf Concepts for the C++0x Standard Library: Iterators (Revision 2): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2323.pdf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-459) time_get::date_order() should return actually date order taken from locale
[ https://issues.apache.org/jira/browse/STDCXX-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-459: - Attachment: (was: stdcxx-459.patch) time_get::date_order() should return actually date order taken from locale -- Key: STDCXX-459 URL: https://issues.apache.org/jira/browse/STDCXX-459 Project: C++ Standard Library Issue Type: Improvement Components: 22. Localization Affects Versions: 4.1.2, 4.1.3, 4.1.4 Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 Attachments: stdcxx-459.patch The current implementation of the time_get::date_order() always returns no_order. It should return date order used by a locale facet (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03734.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-459) time_get::date_order() should return actually date order taken from locale
[ https://issues.apache.org/jira/browse/STDCXX-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546853 ] Farid Zaripov commented on STDCXX-459: -- ChangeLog: STDCXX-459 * include/loc/_time_get.h (__rw_get_timepunct): Removed unnecessary declaration of the function. (do_date_order): Function outlined and moved from here... * include/loc/_time_get.cc (do_date_order):... to here. Used __rw_get_dateorder() to obtain the dateorder value. (__rw_get_dateorder): Added declaration of the new function. (__rw_get_timepunct): Removed unnecessary _RWSTD_EXPORT attribute. * src/time_get.cpp (__rw_get_dateorder): Added new function to obtain the dateorder value. * src/time_put.cpp (__rw_get_timepunct): Removed unnecessary _RWSTD_EXPORT attribute. time_get::date_order() should return actually date order taken from locale -- Key: STDCXX-459 URL: https://issues.apache.org/jira/browse/STDCXX-459 Project: C++ Standard Library Issue Type: Improvement Components: 22. Localization Affects Versions: 4.1.2, 4.1.3, 4.1.4 Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 Attachments: stdcxx-459.patch The current implementation of the time_get::date_order() always returns no_order. It should return date order used by a locale facet (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03734.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (STDCXX-375) std::getline() declared in istream, but should be declared in string
[
https://issues.apache.org/jira/browse/STDCXX-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546884
]
farid edited comment on STDCXX-375 at 11/29/07 12:53 PM:
-
I've tried to declare the std::getline() in this testcase.
The following test fails to compile in MSVC with error: error C2027: use of
undefined type 'std::basic_istream_CharT' in line 16.
---
#include string
#include iosfwd
namespace std {
templateclass _CharT, class _Traits, class _Allocator
basic_istream_CharT, _Traits
getline (basic_istream_CharT, _Traits,
basic_string_CharT, _Traits, _Allocator);
}
void test (std::istream is)
{
std::string str;
std::getline (is, str); /// line 16
}
---
But if I change the test() function to return the is, the test has compiled
without errors.
---
std::istream test (std::istream is)
{
std::string str;
return std::getline (is, str);
}
---
was (Author: farid):
I've tried to declare the std::getline() in this testcase.
The following test fails to compile in MSVC with error: error C2027: use of
undefined type 'std::basic_istream_CharT' in line 16.
---
#include string
#include iosfwd
namespace std {
templateclass _CharT, class _Traits, class _Allocator
basic_istream_CharT, _Traits
getline (basic_istream_CharT, _Traits,
basic_string_CharT, _Traits, _Allocator);
}
void test (std::istream is)
{
std::string str;
std::getline (is, str);
}
---
But if I change the test() function to return the is, the test has compiled
without errors.
---
std::istream void test (std::istream is)
{
std::string str;
return std::getline (is, str);
}
---
std::getline() declared in istream, but should be declared in string
Key: STDCXX-375
URL: https://issues.apache.org/jira/browse/STDCXX-375
Project: C++ Standard Library
Issue Type: Bug
Components: 21. Strings
Affects Versions: 4.1.3, 4.1.4
Environment: All
Reporter: Farid Zaripov
Fix For: 4.2.1
The following code fails to compile with errors:
test.cpp(7) : error C2039: 'getline' : is not a member of 'std'
test.cpp(7) : error C3861: 'getline': identifier not found, even with
argument-dependent lookup
test.cpp:
---
#include string
#include iosfwd
void test (std::istream is)
{
std::string str;
std::getline (is, str);
}
---
The addition information here:
http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200703.mbox/[EMAIL
PROTECTED]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-674) Improve configure script to lookup the dependencies through the all included headers
Improve configure script to lookup the dependencies through the all included headers Key: STDCXX-674 URL: https://issues.apache.org/jira/browse/STDCXX-674 Project: C++ Standard Library Issue Type: Improvement Components: Configuration Affects Versions: 4.2.0, 4.1.4, 4.1.3, 4.1.2 Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.x The addition information here: http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg06170.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-250) std::operator(istream, string) fails to set failbit after it extracts 0 characters
[
https://issues.apache.org/jira/browse/STDCXX-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov reassigned STDCXX-250:
Assignee: Farid Zaripov
std::operator(istream, string) fails to set failbit after it extracts 0
characters
--
Key: STDCXX-250
URL: https://issues.apache.org/jira/browse/STDCXX-250
Project: C++ Standard Library
Issue Type: Bug
Components: 27. Input/Output
Affects Versions: 4.1.2, 4.1.3
Environment: all
Reporter: Martin Sebor
Assignee: Farid Zaripov
Priority: Minor
Fix For: 4.2.1
Attachments: istream.cc.diff
21.3.7.9, p3 says about the string extractor: If the function extracts no
characters, it calls is.setstate(ios::failbit), which may throw
ios_base::failure (27.4.4.3). The test program below shows that in
unbuffered mode stdcxx fails to do so when an exception is thrown during the
third call to underflow().
$ cat v.cpp make v ./v
#include cassert
#include cstdio
#include istream
#include string
int main ()
{
struct: std::streambuf {
int_type underflow () {
static int i = 0;
// i == 0: sgect() invoked from sentry ctor
// i == 1: sgetc() invoked from operator()
// i == 2: sbumpc() invoked from operator()
return 1 i++ ? throw i : 'x';
}
} buf;
std::istream is (buf);
std::string s;
is s;
std::printf (state = %c%c%c, string = \%s\ (length %u)\n,
is.rdstate () is.badbit ? 'B' : '-',
is.rdstate () is.eofbit ? 'E' : '-',
is.rdstate () is.failbit ? 'F' : '-',
s.c_str (), s.size ());
assert (x == s);
assert ((is.failbit | is.badbit) == is.rdstate ());
}
gcc -c -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG -pthreads
-D_RWSTD_USE_CONFIG -I/build/sebor/dev/stdlib/include
-I/build/sebor/gcc-4.1.0-15s/include -I/build/sebor/dev/stdlib/../rwtest
-I/build/sebor/dev/stdlib/../rwtest/include
-I/build/sebor/dev/stdlib/tests/include -pedantic -nostdinc++ -g -W -Wall
-Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long v.cpp
gcc v.o -o v -L/build/sebor/gcc-4.1.0-15s/rwtest -lrwtest15s -pthreads
-L/build/sebor/gcc-4.1.0-15s/lib -lstd15s -lsupc++ -lm
state = B--, string = x (length 1)
Assertion failed: (is.failbit | is.badbit) == is.rdstate (), file v.cpp, line
30
Abort (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-250) std::operator(istream, string) fails to set failbit after it extracts 0 characters
[
https://issues.apache.org/jira/browse/STDCXX-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546300
]
Farid Zaripov commented on STDCXX-250:
--
Does the term extracted means that the gptr() should be shifted by one
position?
std::operator(istream, string) fails to set failbit after it extracts 0
characters
--
Key: STDCXX-250
URL: https://issues.apache.org/jira/browse/STDCXX-250
Project: C++ Standard Library
Issue Type: Bug
Components: 27. Input/Output
Affects Versions: 4.1.2, 4.1.3
Environment: all
Reporter: Martin Sebor
Assignee: Farid Zaripov
Priority: Minor
Fix For: 4.2.1
Attachments: istream.cc.diff
21.3.7.9, p3 says about the string extractor: If the function extracts no
characters, it calls is.setstate(ios::failbit), which may throw
ios_base::failure (27.4.4.3). The test program below shows that in
unbuffered mode stdcxx fails to do so when an exception is thrown during the
third call to underflow().
$ cat v.cpp make v ./v
#include cassert
#include cstdio
#include istream
#include string
int main ()
{
struct: std::streambuf {
int_type underflow () {
static int i = 0;
// i == 0: sgect() invoked from sentry ctor
// i == 1: sgetc() invoked from operator()
// i == 2: sbumpc() invoked from operator()
return 1 i++ ? throw i : 'x';
}
} buf;
std::istream is (buf);
std::string s;
is s;
std::printf (state = %c%c%c, string = \%s\ (length %u)\n,
is.rdstate () is.badbit ? 'B' : '-',
is.rdstate () is.eofbit ? 'E' : '-',
is.rdstate () is.failbit ? 'F' : '-',
s.c_str (), s.size ());
assert (x == s);
assert ((is.failbit | is.badbit) == is.rdstate ());
}
gcc -c -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG -pthreads
-D_RWSTD_USE_CONFIG -I/build/sebor/dev/stdlib/include
-I/build/sebor/gcc-4.1.0-15s/include -I/build/sebor/dev/stdlib/../rwtest
-I/build/sebor/dev/stdlib/../rwtest/include
-I/build/sebor/dev/stdlib/tests/include -pedantic -nostdinc++ -g -W -Wall
-Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long v.cpp
gcc v.o -o v -L/build/sebor/gcc-4.1.0-15s/rwtest -lrwtest15s -pthreads
-L/build/sebor/gcc-4.1.0-15s/lib -lstd15s -lsupc++ -lm
state = B--, string = x (length 1)
Assertion failed: (is.failbit | is.badbit) == is.rdstate (), file v.cpp, line
30
Abort (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-221) std::istream::readsome() sets badbit instead of eofbit on EOF
[ https://issues.apache.org/jira/browse/STDCXX-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545026 ] Farid Zaripov commented on STDCXX-221: -- Can't reproduce. The 27.istream.readsome.cpp test runs without assertions. std::istream::readsome() sets badbit instead of eofbit on EOF - Key: STDCXX-221 URL: https://issues.apache.org/jira/browse/STDCXX-221 Project: C++ Standard Library Issue Type: Bug Components: 27. Input/Output Affects Versions: 4.1.2, 4.1.3 Environment: all Reporter: Martin Sebor Fix For: 4.2.1 Moved from the Rogue Wave bug tracking database (no test case or any detail beyond what's in the summary provided). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-637) [_MSC_VER] 21.cwchar test fails
[ https://issues.apache.org/jira/browse/STDCXX-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov reassigned STDCXX-637: Assignee: Farid Zaripov [_MSC_VER] 21.cwchar test fails --- Key: STDCXX-637 URL: https://issues.apache.org/jira/browse/STDCXX-637 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.2.0 Environment: MSVC, ICC/Windows Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor The 21.cwchar.cpp test fails with the following assertions: --- # ASSERTION (S7) (4 lines): # TEXT: masking macro getwc unexpectedly defined # CLAUSE: lib.c.strings # LINE: 512 # ASSERTION (S7) (4 lines): # TEXT: masking macro putwc unexpectedly defined # CLAUSE: lib.c.strings # LINE: 512 # ASSERTION (S7) (4 lines): # TEXT: std::wcstok() not declared (_RWSTD_NO_WCSTOK = 0, _RWSTD_NO_WCSTOK_IN_LIBC = 0) # CLAUSE: lib.c.strings # LINE: 916 --- Also there are another assertions (see below), but I think these assertions should be avoided when _RWSTD_NO_XXX == 1 _RWSTD_NO_XXX_IN_LIBC == 1 --- # ASSERTION (S7) (4 lines): # TEXT: std::btowc() not declared (_RWSTD_NO_BTOWC = 1, _RWSTD_NO_BTOWC_IN_LIBC = 1) # CLAUSE: lib.c.strings # LINE: 942 # ASSERTION (S7) (4 lines): # TEXT: std::wctob() not declared (_RWSTD_NO_WCTOB = 1, _RWSTD_NO_WCTOB_IN_LIBC = 1) # CLAUSE: lib.c.strings # LINE: 943 # ASSERTION (S7) (4 lines): # TEXT: std::mbrlen() not declared (_RWSTD_NO_MBRLEN = 1, _RWSTD_NO_MBRLEN_IN_LIBC = 1) # CLAUSE: lib.c.strings # LINE: 948 # ASSERTION (S7) (4 lines): # TEXT: std::mbrtowc() not declared (_RWSTD_NO_MBRTOWC = 1, _RWSTD_NO_MBRTOWC_IN_LIBC = 1) # CLAUSE: lib.c.strings # LINE: 949 # ASSERTION (S7) (4 lines): # TEXT: std::wcrtomb() not declared (_RWSTD_NO_WCRTOMB = 1, _RWSTD_NO_WCRTOMB_IN_LIBC = 1) # CLAUSE: lib.c.strings # LINE: 950 # ASSERTION (S7) (4 lines): # TEXT: std::mbsrtowcs() not declared (_RWSTD_NO_MBSRTOWCS = 1, _RWSTD_NO_MBSRTOWCS_IN_LIBC = 1) # CLAUSE: lib.c.strings # LINE: 952 # ASSERTION (S7) (4 lines): # TEXT: std::wcsrtombs() not declared (_RWSTD_NO_WCSRTOMBS = 1, _RWSTD_NO_WCSRTOMBS_IN_LIBC = 1) # CLAUSE: lib.c.strings # LINE: 953 --- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-671) Rename _V3_USE_FACET macro to _RWSTD_USE_FACET
[ https://issues.apache.org/jira/browse/STDCXX-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-671: - Description: The macro _V3_USE_FACET should be renamed to _RWSTD_USE_FACET since the deprecated _V3_LOCALE macro were removed in STDCXX-594. (was: The macro _V3_USE_FACET should be renamed to _RW_USE_FACET since the deprecated _V3_LOCALE macro were removed in STDCXX-594.) Summary: Rename _V3_USE_FACET macro to _RWSTD_USE_FACET (was: Rename _V3_USE_FACET macro to _RW_USE_FACET) _RW_USE_FACET changed to _RWSTD_USE_FACET Rename _V3_USE_FACET macro to _RWSTD_USE_FACET -- Key: STDCXX-671 URL: https://issues.apache.org/jira/browse/STDCXX-671 Project: C++ Standard Library Issue Type: Improvement Components: 22. Localization Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Trivial Fix For: 4.2.1 The macro _V3_USE_FACET should be renamed to _RWSTD_USE_FACET since the deprecated _V3_LOCALE macro were removed in STDCXX-594. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-671) Rename _V3_USE_FACET macro to _RWSTD_USE_FACET
[ https://issues.apache.org/jira/browse/STDCXX-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-671. -- Resolution: Fixed Rename _V3_USE_FACET macro to _RWSTD_USE_FACET -- Key: STDCXX-671 URL: https://issues.apache.org/jira/browse/STDCXX-671 Project: C++ Standard Library Issue Type: Improvement Components: 22. Localization Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Trivial Fix For: 4.2.1 The macro _V3_USE_FACET should be renamed to _RWSTD_USE_FACET since the deprecated _V3_LOCALE macro were removed in STDCXX-594. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-637) [_MSC_VER] 21.cwchar test fails
[ https://issues.apache.org/jira/browse/STDCXX-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-637. -- Resolution: Fixed Fix Version/s: 4.2.1 [_MSC_VER] 21.cwchar test fails --- Key: STDCXX-637 URL: https://issues.apache.org/jira/browse/STDCXX-637 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.2.0 Environment: MSVC, ICC/Windows Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 The 21.cwchar.cpp test fails with the following assertions: --- # ASSERTION (S7) (4 lines): # TEXT: masking macro getwc unexpectedly defined # CLAUSE: lib.c.strings # LINE: 512 # ASSERTION (S7) (4 lines): # TEXT: masking macro putwc unexpectedly defined # CLAUSE: lib.c.strings # LINE: 512 # ASSERTION (S7) (4 lines): # TEXT: std::wcstok() not declared (_RWSTD_NO_WCSTOK = 0, _RWSTD_NO_WCSTOK_IN_LIBC = 0) # CLAUSE: lib.c.strings # LINE: 916 --- Also there are another assertions (see below), but I think these assertions should be avoided when _RWSTD_NO_XXX == 1 _RWSTD_NO_XXX_IN_LIBC == 1 --- # ASSERTION (S7) (4 lines): # TEXT: std::btowc() not declared (_RWSTD_NO_BTOWC = 1, _RWSTD_NO_BTOWC_IN_LIBC = 1) # CLAUSE: lib.c.strings # LINE: 942 # ASSERTION (S7) (4 lines): # TEXT: std::wctob() not declared (_RWSTD_NO_WCTOB = 1, _RWSTD_NO_WCTOB_IN_LIBC = 1) # CLAUSE: lib.c.strings # LINE: 943 # ASSERTION (S7) (4 lines): # TEXT: std::mbrlen() not declared (_RWSTD_NO_MBRLEN = 1, _RWSTD_NO_MBRLEN_IN_LIBC = 1) # CLAUSE: lib.c.strings # LINE: 948 # ASSERTION (S7) (4 lines): # TEXT: std::mbrtowc() not declared (_RWSTD_NO_MBRTOWC = 1, _RWSTD_NO_MBRTOWC_IN_LIBC = 1) # CLAUSE: lib.c.strings # LINE: 949 # ASSERTION (S7) (4 lines): # TEXT: std::wcrtomb() not declared (_RWSTD_NO_WCRTOMB = 1, _RWSTD_NO_WCRTOMB_IN_LIBC = 1) # CLAUSE: lib.c.strings # LINE: 950 # ASSERTION (S7) (4 lines): # TEXT: std::mbsrtowcs() not declared (_RWSTD_NO_MBSRTOWCS = 1, _RWSTD_NO_MBSRTOWCS_IN_LIBC = 1) # CLAUSE: lib.c.strings # LINE: 952 # ASSERTION (S7) (4 lines): # TEXT: std::wcsrtombs() not declared (_RWSTD_NO_WCSRTOMBS = 1, _RWSTD_NO_WCSRTOMBS_IN_LIBC = 1) # CLAUSE: lib.c.strings # LINE: 953 --- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-585) [gcc 4.2.0/Cygwin] linker errors due to multiple definition of `std::bad_cast::what()'; `std::bad_typeid::what()'; `std::bad_exception::what()'; `std::bad_alloc::what()'
[ https://issues.apache.org/jira/browse/STDCXX-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-585: - Patch Info: [Patch Available] [gcc 4.2.0/Cygwin] linker errors due to multiple definition of `std::bad_cast::what()'; `std::bad_typeid::what()'; `std::bad_exception::what()'; `std::bad_alloc::what()' - Key: STDCXX-585 URL: https://issues.apache.org/jira/browse/STDCXX-585 Project: C++ Standard Library Issue Type: Bug Components: Configuration Affects Versions: 4.2.0 Environment: gcc 4.2.0 / Cygwin Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Blocker Fix For: 4.2.1 Attachments: BAD_ALLOC_ASSIGNMENT.cpp.diff When building the stdcxx on Cygwin I get errors like: make: Entering directory `/usr/src/stdcxx/trunk/build/examples' gcc -c -I/usr/src/stdcxx/trunk/include/ansi -D_RWSTDDEBUG -D_REENTRANT -mthreads -I/usr/src/stdcxx/trunk/include -I/usr/src/stdcxx/trunk/build/include -I/usr/src/stdcxx/trunk/examples/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align /usr/src/stdcxx/trunk/examples/manual/accumulate.cpp gcc accumulate.o -o accumulate -mthreads -L/usr/src/stdcxx/trunk/build/lib -lstd15s -lsupc++ -lcatgets -liconv -lm /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(tinfo.o): In function `_ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastEiNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16__dyncast_resultE': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/tinfo.cc:418: multiple definition of `std::bad_cast::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(typeinfo.o):/usr/src/stdcxx/trunk/src/typeinfo.cpp:349: first defined here /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(tinfo.o): In function `_ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastEiNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16__dyncast_resultE': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/tinfo.cc:418: multiple definition of `std::bad_typeid::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(typeinfo.o):/usr/src/stdcxx/trunk/src/typeinfo.cpp:414: first defined here /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(new_handler.o): In function `_ZNSt9bad_allocD2Ev': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/new_handler.cc:48: multiple definition of `std::bad_alloc::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(memory.o):/usr/src/stdcxx/trunk/src/memory.cpp:331: first defined here /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(eh_exception.o): In function `_ZNSt13bad_exceptionD2Ev': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/eh_exception.cc:38: multiple definition of `std::bad_exception::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(exception.o):/usr/src/stdcxx/trunk/src/exception.cpp:412: first defined here collect2: ld returned 1 exit status make: *** [accumulate] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-585) [gcc 4.2.0/Cygwin] linker errors due to multiple definition of `std::bad_cast::what()'; `std::bad_typeid::what()'; `std::bad_exception::what()'; `std::bad_alloc::what()'
[ https://issues.apache.org/jira/browse/STDCXX-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-585: - Attachment: BAD_ALLOC_ASSIGNMENT.cpp.diff The patch is attached. [gcc 4.2.0/Cygwin] linker errors due to multiple definition of `std::bad_cast::what()'; `std::bad_typeid::what()'; `std::bad_exception::what()'; `std::bad_alloc::what()' - Key: STDCXX-585 URL: https://issues.apache.org/jira/browse/STDCXX-585 Project: C++ Standard Library Issue Type: Bug Components: Configuration Affects Versions: 4.2.0 Environment: gcc 4.2.0 / Cygwin Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Blocker Fix For: 4.2.1 Attachments: BAD_ALLOC_ASSIGNMENT.cpp.diff When building the stdcxx on Cygwin I get errors like: make: Entering directory `/usr/src/stdcxx/trunk/build/examples' gcc -c -I/usr/src/stdcxx/trunk/include/ansi -D_RWSTDDEBUG -D_REENTRANT -mthreads -I/usr/src/stdcxx/trunk/include -I/usr/src/stdcxx/trunk/build/include -I/usr/src/stdcxx/trunk/examples/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align /usr/src/stdcxx/trunk/examples/manual/accumulate.cpp gcc accumulate.o -o accumulate -mthreads -L/usr/src/stdcxx/trunk/build/lib -lstd15s -lsupc++ -lcatgets -liconv -lm /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(tinfo.o): In function `_ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastEiNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16__dyncast_resultE': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/tinfo.cc:418: multiple definition of `std::bad_cast::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(typeinfo.o):/usr/src/stdcxx/trunk/src/typeinfo.cpp:349: first defined here /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(tinfo.o): In function `_ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastEiNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16__dyncast_resultE': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/tinfo.cc:418: multiple definition of `std::bad_typeid::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(typeinfo.o):/usr/src/stdcxx/trunk/src/typeinfo.cpp:414: first defined here /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(new_handler.o): In function `_ZNSt9bad_allocD2Ev': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/new_handler.cc:48: multiple definition of `std::bad_alloc::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(memory.o):/usr/src/stdcxx/trunk/src/memory.cpp:331: first defined here /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(eh_exception.o): In function `_ZNSt13bad_exceptionD2Ev': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/eh_exception.cc:38: multiple definition of `std::bad_exception::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(exception.o):/usr/src/stdcxx/trunk/src/exception.cpp:412: first defined here collect2: ld returned 1 exit status make: *** [accumulate] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-585) [gcc 4.2.0/Cygwin] linker errors due to multiple definition of `std::bad_cast::what()'; `std::bad_typeid::what()'; `std::bad_exception::what()'; `std::bad_alloc::what()'
[ https://issues.apache.org/jira/browse/STDCXX-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544875 ] Farid Zaripov commented on STDCXX-585: -- ChangeLog: 2007-11-22 Farid Zaripov [EMAIL PROTECTED] STDCXX-585 * BAD_ALLOC_ASSIGNMENT.cpp: Don't define ~bad_alloc() when testing the presence of the other members to avoid multiply defined sybmol linker errors. [gcc 4.2.0/Cygwin] linker errors due to multiple definition of `std::bad_cast::what()'; `std::bad_typeid::what()'; `std::bad_exception::what()'; `std::bad_alloc::what()' - Key: STDCXX-585 URL: https://issues.apache.org/jira/browse/STDCXX-585 Project: C++ Standard Library Issue Type: Bug Components: Configuration Affects Versions: 4.2.0 Environment: gcc 4.2.0 / Cygwin Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Blocker Fix For: 4.2.1 Attachments: BAD_ALLOC_ASSIGNMENT.cpp.diff When building the stdcxx on Cygwin I get errors like: make: Entering directory `/usr/src/stdcxx/trunk/build/examples' gcc -c -I/usr/src/stdcxx/trunk/include/ansi -D_RWSTDDEBUG -D_REENTRANT -mthreads -I/usr/src/stdcxx/trunk/include -I/usr/src/stdcxx/trunk/build/include -I/usr/src/stdcxx/trunk/examples/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align /usr/src/stdcxx/trunk/examples/manual/accumulate.cpp gcc accumulate.o -o accumulate -mthreads -L/usr/src/stdcxx/trunk/build/lib -lstd15s -lsupc++ -lcatgets -liconv -lm /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(tinfo.o): In function `_ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastEiNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16__dyncast_resultE': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/tinfo.cc:418: multiple definition of `std::bad_cast::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(typeinfo.o):/usr/src/stdcxx/trunk/src/typeinfo.cpp:349: first defined here /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(tinfo.o): In function `_ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastEiNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16__dyncast_resultE': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/tinfo.cc:418: multiple definition of `std::bad_typeid::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(typeinfo.o):/usr/src/stdcxx/trunk/src/typeinfo.cpp:414: first defined here /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(new_handler.o): In function `_ZNSt9bad_allocD2Ev': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/new_handler.cc:48: multiple definition of `std::bad_alloc::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(memory.o):/usr/src/stdcxx/trunk/src/memory.cpp:331: first defined here /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(eh_exception.o): In function `_ZNSt13bad_exceptionD2Ev': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/eh_exception.cc:38: multiple definition of `std::bad_exception::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(exception.o):/usr/src/stdcxx/trunk/src/exception.cpp:412: first defined here collect2: ld returned 1 exit status make: *** [accumulate] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-557) Make definitions of std::terminate() consistent in all config test sources.
[ https://issues.apache.org/jira/browse/STDCXX-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-557. -- Resolution: Fixed Make definitions of std::terminate() consistent in all config test sources. --- Key: STDCXX-557 URL: https://issues.apache.org/jira/browse/STDCXX-557 Project: C++ Standard Library Issue Type: Improvement Components: Configuration Reporter: Eric Lemings Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 Attachments: terminate.patch Many of the source files for the config tests (in etc/config/src directory) contain inconsistent definitions for the std::terminate() function. Suggest making them all consistent, ideally by creating a new file with a single definition that is included where needed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-558) Remove unnecessary includes of config.h in source files for config tests
[ https://issues.apache.org/jira/browse/STDCXX-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-558. -- Resolution: Fixed Remove unnecessary includes of config.h in source files for config tests -- Key: STDCXX-558 URL: https://issues.apache.org/jira/browse/STDCXX-558 Project: C++ Standard Library Issue Type: Improvement Components: Configuration Reporter: Eric Lemings Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 Several config tests in the etc/config/src directory unnecessarily include the config.h header. Need to review each source file that includes this header and remove the directive if it is not really needed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-558) Remove unnecessary includes of config.h in source files for config tests
[ https://issues.apache.org/jira/browse/STDCXX-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov closed STDCXX-558. Remove unnecessary includes of config.h in source files for config tests -- Key: STDCXX-558 URL: https://issues.apache.org/jira/browse/STDCXX-558 Project: C++ Standard Library Issue Type: Improvement Components: Configuration Reporter: Eric Lemings Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 Several config tests in the etc/config/src directory unnecessarily include the config.h header. Need to review each source file that includes this header and remove the directive if it is not really needed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-630) 21.string.assign test fails
[ https://issues.apache.org/jira/browse/STDCXX-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov reassigned STDCXX-630: Assignee: Farid Zaripov 21.string.assign test fails --- Key: STDCXX-630 URL: https://issues.apache.org/jira/browse/STDCXX-630 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.2.0 Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 The 21.string.append test fails because of STDCXX-629. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-629) std::string::assign (reverse_iterator, reverse_iterator) assigning self incorrect
[
https://issues.apache.org/jira/browse/STDCXX-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov reassigned STDCXX-629:
Assignee: Farid Zaripov
std::string::assign (reverse_iterator, reverse_iterator) assigning self
incorrect
-
Key: STDCXX-629
URL: https://issues.apache.org/jira/browse/STDCXX-629
Project: C++ Standard Library
Issue Type: Bug
Components: 21. Strings
Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0
Environment: All
Reporter: Farid Zaripov
Assignee: Farid Zaripov
Priority: Minor
Fix For: 4.2.1
The 21.string.assign.cpp test has been failing a number of assertions for
self-referential test cases that exercise the ability to assign a substring
of a string into itself using the assign(InputIterator, InputIterator) member
template specialization for InputIterator being an actual reverse_iterator.
The program below reproduces the problem in a small isolated test case.
#include cassert
#include string
int main ()
{
std::string s (abc);
s.assign (s.rbegin () + 1, s.rend ());
assert (ba == s);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-585) [gcc 4.2.0/Cygwin] linker errors due to multiple definition of `std::bad_cast::what()'; `std::bad_typeid::what()'; `std::bad_exception::what()'; `std::bad_alloc::what()'
[ https://issues.apache.org/jira/browse/STDCXX-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov reassigned STDCXX-585: Assignee: Farid Zaripov [gcc 4.2.0/Cygwin] linker errors due to multiple definition of `std::bad_cast::what()'; `std::bad_typeid::what()'; `std::bad_exception::what()'; `std::bad_alloc::what()' - Key: STDCXX-585 URL: https://issues.apache.org/jira/browse/STDCXX-585 Project: C++ Standard Library Issue Type: Bug Components: Configuration Affects Versions: 4.2.0 Environment: gcc 4.2.0 / Cygwin Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Blocker Fix For: 4.2.1 When building the stdcxx on Cygwin I get errors like: make: Entering directory `/usr/src/stdcxx/trunk/build/examples' gcc -c -I/usr/src/stdcxx/trunk/include/ansi -D_RWSTDDEBUG -D_REENTRANT -mthreads -I/usr/src/stdcxx/trunk/include -I/usr/src/stdcxx/trunk/build/include -I/usr/src/stdcxx/trunk/examples/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align /usr/src/stdcxx/trunk/examples/manual/accumulate.cpp gcc accumulate.o -o accumulate -mthreads -L/usr/src/stdcxx/trunk/build/lib -lstd15s -lsupc++ -lcatgets -liconv -lm /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(tinfo.o): In function `_ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastEiNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16__dyncast_resultE': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/tinfo.cc:418: multiple definition of `std::bad_cast::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(typeinfo.o):/usr/src/stdcxx/trunk/src/typeinfo.cpp:349: first defined here /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(tinfo.o): In function `_ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastEiNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16__dyncast_resultE': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/tinfo.cc:418: multiple definition of `std::bad_typeid::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(typeinfo.o):/usr/src/stdcxx/trunk/src/typeinfo.cpp:414: first defined here /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(new_handler.o): In function `_ZNSt9bad_allocD2Ev': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/new_handler.cc:48: multiple definition of `std::bad_alloc::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(memory.o):/usr/src/stdcxx/trunk/src/memory.cpp:331: first defined here /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(eh_exception.o): In function `_ZNSt13bad_exceptionD2Ev': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/eh_exception.cc:38: multiple definition of `std::bad_exception::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(exception.o):/usr/src/stdcxx/trunk/src/exception.cpp:412: first defined here collect2: ld returned 1 exit status make: *** [accumulate] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-594) remove _V3_LOCALE macro from headers and sources
[ https://issues.apache.org/jira/browse/STDCXX-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544562 ] Farid Zaripov commented on STDCXX-594: -- Maybe we should also rename _V3_USE_FACET() macro to i.e. _RW_USE_FACET() (the _STD_USE_FACET() and _USE_FACET() macros are already defined). remove _V3_LOCALE macro from headers and sources Key: STDCXX-594 URL: https://issues.apache.org/jira/browse/STDCXX-594 Project: C++ Standard Library Issue Type: Task Components: 22. Localization Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 Environment: all Reporter: Martin Sebor Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 The macro _V3_LOCALE that appears in a number headers and sources is unused and should be removed, Here's a list of library files where the macro appears. There might be other occurrences in tests and elsewhere. $ find ~/stdcxx/include/ ~/stdcxx/src/ -type f | xargs grep -l _V3_LOCALE | grep -v -e /.svn/ -e ~ /nfs/homes/sebor/stdcxx/include/loc/_time_get.cc /nfs/homes/sebor/stdcxx/include/loc/_convenience.h /nfs/homes/sebor/stdcxx/include/loc/_locale.h /nfs/homes/sebor/stdcxx/include/loc/_moneypunct.h /nfs/homes/sebor/stdcxx/include/loc/_messages.h /nfs/homes/sebor/stdcxx/include/loc/_numpunct.h /nfs/homes/sebor/stdcxx/include/loc/_money_put.cc /nfs/homes/sebor/stdcxx/include/loc/_collate.h /nfs/homes/sebor/stdcxx/include/loc/_money_get.cc /nfs/homes/sebor/stdcxx/include/loc/_num_put.cc /nfs/homes/sebor/stdcxx/include/loc/_codecvt.cc /nfs/homes/sebor/stdcxx/include/loc/_num_get.cc /nfs/homes/sebor/stdcxx/include/loc/_moneypunct.cc /nfs/homes/sebor/stdcxx/include/loc/_messages.cc /nfs/homes/sebor/stdcxx/include/loc/_numpunct.cc /nfs/homes/sebor/stdcxx/include/loc/_collate.cc /nfs/homes/sebor/stdcxx/include/loc/_ctype.cc /nfs/homes/sebor/stdcxx/include/loc/_ctype.h /nfs/homes/sebor/stdcxx/include/loc/_codecvt.h /nfs/homes/sebor/stdcxx/include/loc/_time_put.cc /nfs/homes/sebor/stdcxx/include/rw/_defs.h /nfs/homes/sebor/stdcxx/src/ChangeLog -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-594) remove _V3_LOCALE macro from headers and sources
[ https://issues.apache.org/jira/browse/STDCXX-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov reassigned STDCXX-594: Assignee: Farid Zaripov remove _V3_LOCALE macro from headers and sources Key: STDCXX-594 URL: https://issues.apache.org/jira/browse/STDCXX-594 Project: C++ Standard Library Issue Type: Task Components: 22. Localization Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 Environment: all Reporter: Martin Sebor Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 The macro _V3_LOCALE that appears in a number headers and sources is unused and should be removed, Here's a list of library files where the macro appears. There might be other occurrences in tests and elsewhere. $ find ~/stdcxx/include/ ~/stdcxx/src/ -type f | xargs grep -l _V3_LOCALE | grep -v -e /.svn/ -e ~ /nfs/homes/sebor/stdcxx/include/loc/_time_get.cc /nfs/homes/sebor/stdcxx/include/loc/_convenience.h /nfs/homes/sebor/stdcxx/include/loc/_locale.h /nfs/homes/sebor/stdcxx/include/loc/_moneypunct.h /nfs/homes/sebor/stdcxx/include/loc/_messages.h /nfs/homes/sebor/stdcxx/include/loc/_numpunct.h /nfs/homes/sebor/stdcxx/include/loc/_money_put.cc /nfs/homes/sebor/stdcxx/include/loc/_collate.h /nfs/homes/sebor/stdcxx/include/loc/_money_get.cc /nfs/homes/sebor/stdcxx/include/loc/_num_put.cc /nfs/homes/sebor/stdcxx/include/loc/_codecvt.cc /nfs/homes/sebor/stdcxx/include/loc/_num_get.cc /nfs/homes/sebor/stdcxx/include/loc/_moneypunct.cc /nfs/homes/sebor/stdcxx/include/loc/_messages.cc /nfs/homes/sebor/stdcxx/include/loc/_numpunct.cc /nfs/homes/sebor/stdcxx/include/loc/_collate.cc /nfs/homes/sebor/stdcxx/include/loc/_ctype.cc /nfs/homes/sebor/stdcxx/include/loc/_ctype.h /nfs/homes/sebor/stdcxx/include/loc/_codecvt.h /nfs/homes/sebor/stdcxx/include/loc/_time_put.cc /nfs/homes/sebor/stdcxx/include/rw/_defs.h /nfs/homes/sebor/stdcxx/src/ChangeLog -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-438) std::string::append (InputIterator, InputIterator) appending self incorrect
[
https://issues.apache.org/jira/browse/STDCXX-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov reassigned STDCXX-438:
Assignee: Farid Zaripov
std::string::append (InputIterator, InputIterator) appending self incorrect
---
Key: STDCXX-438
URL: https://issues.apache.org/jira/browse/STDCXX-438
Project: C++ Standard Library
Issue Type: Bug
Components: 21. Strings
Affects Versions: 4.1.2, 4.1.3
Environment: all
Reporter: Martin Sebor
Assignee: Farid Zaripov
Priority: Minor
Fix For: 4.2.1
The 21.string.append.cpp test has been failing a number of assertions for
self-referential test cases that exercise the ability to append a substring
of a string into itself using the append(InputIterator, InputIterator) member
template specialization for InputIterator being an actual Input Iterator. The
program below reproduces the problem in a small isolated test case.
$ cat t.cpp gmake t ./t
#include cassert
#include cstdlib
#include cstring
#include iterator
#include new
#include string
void* operator new (std::size_t n) throw (std::bad_alloc)
{
void* const ptr = std::malloc (n + sizeof n);
std::memset (ptr, -1, n);
*(std::size_t*)ptr = n;
return (std::size_t*)ptr + 1;
}
void operator delete (void *ptr) throw ()
{
std::memset (ptr, -1, *((std::size_t*)ptr - 1));
std::free ((std::size_t*)ptr - 1);
}
struct InputIterator: std::iteratorstd::input_iterator_tag, char
{
const char *p_;
InputIterator (const char *p): p_ (p) { }
char operator* () const { return *p_; }
InputIterator operator++ () { return ++p_, *this; }
InputIterator operator++ (int) {
return ++p_, InputIterator (p_ - 1);
}
bool operator== (const InputIterator rhs) const { return p_ == rhs.p_; }
};
int main ()
{
const char s[] = abc;
{
std::string str (s);
const char* p0 = s + 1;
const char* p1 = p0 + 1;
const InputIterator first (p0);
const InputIterator last (p1);
str.append (first, last);
assert (abcb == str);
}
{
std::string str (s);
const char* p0 = str.data () + 1;
const char* p1 = p0 + 1;
const InputIterator first (p0);
const InputIterator last (p1);
str.append (first, last);
assert (abcb == str);
}
}
aCC -c -I/amd/devco/sebor/stdcxx/include/ansi -I/usr/include -D_RWSTDDEBUG
-mt -D_RWSTD_USE_CONFIG -I/amd/devco/sebor/stdcxx/include
-I/build/sebor/stdcxx-aCC-3.73-15D/include
-I/amd/devco/sebor/stdcxx/tests/include -Aa +nostl -g +d +DD64 +w +W392
+W655 +W684 +W818 +W819 +W849 t.cpp
aCC t.o -o t -L/build/sebor/stdcxx-aCC-3.73-15D/rwtest -lrwtest15D -Aa +nostl
-Wl,+s -Wl,+vnocompatwarnings -mt +DD64
-L/build/sebor/stdcxx-aCC-3.73-15D/lib
-Wl,+b/build/sebor/stdcxx-aCC-3.73-15D/lib:/build/sebor/stdcxx-aCC-3.73-15D/rwtest
-lstd15D -lm
Assertion failed: abcb == str, file t.cpp, line 67
ABORT instruction (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-632) std::string::insert (iterator, InputIterator, InputIterator) inserting self incorrect
[
https://issues.apache.org/jira/browse/STDCXX-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov reassigned STDCXX-632:
Assignee: Farid Zaripov
std::string::insert (iterator, InputIterator, InputIterator) inserting self
incorrect
-
Key: STDCXX-632
URL: https://issues.apache.org/jira/browse/STDCXX-632
Project: C++ Standard Library
Issue Type: Bug
Components: 21. Strings
Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0
Environment: All
Reporter: Farid Zaripov
Assignee: Farid Zaripov
Priority: Minor
Fix For: 4.2.1
The 21.string.insert.cpp test has been failing a number of assertions for
self-referential test cases that exercise the ability to insert a substring
of a string into itself using the insert(iterator, InputIterator,
InputIterator) member template specialization for InputIterator being an
actual Input Iterator. The program below reproduces the problem in a small
isolated test case.
#include cassert
#include string
int main ()
{
std::string s (abc);
typedef const unsigned char UChar;
s.insert (s.begin (), (UChar*)s [1], (UChar*)s [2]);
assert (babc == s);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-631) 21.string.replace test fails
[ https://issues.apache.org/jira/browse/STDCXX-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov reassigned STDCXX-631: Assignee: Farid Zaripov 21.string.replace test fails Key: STDCXX-631 URL: https://issues.apache.org/jira/browse/STDCXX-631 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.2.0 Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 The 21.string.replace test fails because of STDCXX-170. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-633) 21.string.insert test fails
[ https://issues.apache.org/jira/browse/STDCXX-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov reassigned STDCXX-633: Assignee: Farid Zaripov 21.string.insert test fails --- Key: STDCXX-633 URL: https://issues.apache.org/jira/browse/STDCXX-633 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.2.0 Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 The 21.string.append test fails because of STDCXX-632. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-669) [MSVC 7.1] compilation errors in 20.auto.ptr.cpp
[ https://issues.apache.org/jira/browse/STDCXX-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-669. -- Resolution: Fixed Resolved thus: http://svn.apache.org/viewvc?rev=596354view=rev [MSVC 7.1] compilation errors in 20.auto.ptr.cpp Key: STDCXX-669 URL: https://issues.apache.org/jira/browse/STDCXX-669 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.2.0 Environment: MSVC 7.1 Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 The test 20.auto.ptr.cpp fails to compile with MSVC 7.1: -- Build started: Project: 20.auto.ptr, Configuration: 15s Debug Thread-safe Static Win32 -- Compiling... 20.auto.ptr.cpp \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(212) : error C2440: 'initializing' : cannot convert from 'overloaded-function' to 'std::auto_ptr_ref_TypeT (__thiscall std::auto_ptrDerived::* )(void)' with [ _TypeT=std::auto_ptrBase::element_type ] None of the functions with this name in scope match the target type \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(438) : see reference to function template instantiation 'void test_auto_ptrbool(T *,const char *)' being compiled with [ T=bool ] \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(215) : error C2440: 'initializing' : cannot convert from 'overloaded-function' to 'std::auto_ptr_TypeT (__thiscall std::auto_ptrDerived::* )(void)' with [ _TypeT=Base ] None of the functions with this name in scope match the target type \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(212) : error C2440: 'initializing' : cannot convert from 'overloaded-function' to 'std::auto_ptr_ref_TypeT (__thiscall std::auto_ptrDerived::* )(void)' with [ _TypeT=std::auto_ptrBase::element_type ] None of the functions with this name in scope match the target type \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(442) : see reference to function template instantiation 'void test_auto_ptrchar(T *,const char *)' being compiled with [ T=char ] \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(215) : error C2440: 'initializing' : cannot convert from 'overloaded-function' to 'std::auto_ptr_TypeT (__thiscall std::auto_ptrDerived::* )(void)' with [ _TypeT=Base ] None of the functions with this name in scope match the target type \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(212) : error C2440: 'initializing' : cannot convert from 'overloaded-function' to 'std::auto_ptr_ref_TypeT (__thiscall std::auto_ptrDerived::* )(void)' with [ _TypeT=std::auto_ptrBase::element_type ] None of the functions with this name in scope match the target type \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(443) : see reference to function template instantiation 'void test_auto_ptrint(T *,const char *)' being compiled with [ T=int ] \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(215) : error C2440: 'initializing' : cannot convert from 'overloaded-function' to 'std::auto_ptr_TypeT (__thiscall std::auto_ptrDerived::* )(void)' with [ _TypeT=Base ] None of the functions with this name in scope match the target type \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(212) : error C2440: 'initializing' : cannot convert from 'overloaded-function' to 'std::auto_ptr_ref_TypeT (__thiscall std::auto_ptrDerived::* )(void)' with [ _TypeT=std::auto_ptrBase::element_type ] None of the functions with this name in scope match the target type \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(444) : see reference to function template instantiation 'void test_auto_ptrdouble(T *,const char *)' being compiled with [ T=double ] \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(215) : error C2440: 'initializing' : cannot convert from 'overloaded-function' to 'std::auto_ptr_TypeT (__thiscall std::auto_ptrDerived::* )(void)' with [ _TypeT=Base ] None of the functions with this name in scope match the target type \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(212) : error C2440: 'initializing' : cannot convert from 'overloaded-function' to 'std::auto_ptr_ref_TypeT (__thiscall std::auto_ptrDerived::*
[jira] Closed: (STDCXX-669) [MSVC 7.1] compilation errors in 20.auto.ptr.cpp
[ https://issues.apache.org/jira/browse/STDCXX-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov closed STDCXX-669. [MSVC 7.1] compilation errors in 20.auto.ptr.cpp Key: STDCXX-669 URL: https://issues.apache.org/jira/browse/STDCXX-669 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.2.0 Environment: MSVC 7.1 Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 The test 20.auto.ptr.cpp fails to compile with MSVC 7.1: -- Build started: Project: 20.auto.ptr, Configuration: 15s Debug Thread-safe Static Win32 -- Compiling... 20.auto.ptr.cpp \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(212) : error C2440: 'initializing' : cannot convert from 'overloaded-function' to 'std::auto_ptr_ref_TypeT (__thiscall std::auto_ptrDerived::* )(void)' with [ _TypeT=std::auto_ptrBase::element_type ] None of the functions with this name in scope match the target type \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(438) : see reference to function template instantiation 'void test_auto_ptrbool(T *,const char *)' being compiled with [ T=bool ] \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(215) : error C2440: 'initializing' : cannot convert from 'overloaded-function' to 'std::auto_ptr_TypeT (__thiscall std::auto_ptrDerived::* )(void)' with [ _TypeT=Base ] None of the functions with this name in scope match the target type \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(212) : error C2440: 'initializing' : cannot convert from 'overloaded-function' to 'std::auto_ptr_ref_TypeT (__thiscall std::auto_ptrDerived::* )(void)' with [ _TypeT=std::auto_ptrBase::element_type ] None of the functions with this name in scope match the target type \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(442) : see reference to function template instantiation 'void test_auto_ptrchar(T *,const char *)' being compiled with [ T=char ] \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(215) : error C2440: 'initializing' : cannot convert from 'overloaded-function' to 'std::auto_ptr_TypeT (__thiscall std::auto_ptrDerived::* )(void)' with [ _TypeT=Base ] None of the functions with this name in scope match the target type \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(212) : error C2440: 'initializing' : cannot convert from 'overloaded-function' to 'std::auto_ptr_ref_TypeT (__thiscall std::auto_ptrDerived::* )(void)' with [ _TypeT=std::auto_ptrBase::element_type ] None of the functions with this name in scope match the target type \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(443) : see reference to function template instantiation 'void test_auto_ptrint(T *,const char *)' being compiled with [ T=int ] \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(215) : error C2440: 'initializing' : cannot convert from 'overloaded-function' to 'std::auto_ptr_TypeT (__thiscall std::auto_ptrDerived::* )(void)' with [ _TypeT=Base ] None of the functions with this name in scope match the target type \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(212) : error C2440: 'initializing' : cannot convert from 'overloaded-function' to 'std::auto_ptr_ref_TypeT (__thiscall std::auto_ptrDerived::* )(void)' with [ _TypeT=std::auto_ptrBase::element_type ] None of the functions with this name in scope match the target type \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(444) : see reference to function template instantiation 'void test_auto_ptrdouble(T *,const char *)' being compiled with [ T=double ] \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(215) : error C2440: 'initializing' : cannot convert from 'overloaded-function' to 'std::auto_ptr_TypeT (__thiscall std::auto_ptrDerived::* )(void)' with [ _TypeT=Base ] None of the functions with this name in scope match the target type \stdcxx\stdcxx-4.2.x\tests\utilities\20.auto.ptr.cpp(212) : error C2440: 'initializing' : cannot convert from 'overloaded-function' to 'std::auto_ptr_ref_TypeT (__thiscall std::auto_ptrDerived::* )(void)' with [ _TypeT=std::auto_ptrBase::element_type
[jira] Commented: (STDCXX-612) many iterator types do not work with types that implement unary operator
[
https://issues.apache.org/jira/browse/STDCXX-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543925
]
Farid Zaripov commented on STDCXX-612:
--
ChangeLog:
* include/rw/_defs.h: #define _RWSTD_ADDRESS_OF - new macro to
obtain the memory address of the object.
(_RWSTD_OPERATOR_ARROW): Add type parameter. Use
_RWSTD_ADDRESS_OF() macro.
* include/deque (_RWSTD_OPERATOR_ARROW): Split signature to two
parameters: type and rest.
* include/deque_spec.h (_RWSTD_OPERATOR_ARROW): Ditto.
* include/list (_RWSTD_OPERATOR_ARROW): Ditto.
* include/list_spec.h (_RWSTD_OPERATOR_ARROW): Ditto.
* include/rw/_iterator.h (_RWSTD_OPERATOR_ARROW): Ditto.
* include/rw/_iterbase.h (_RWSTD_OPERATOR_ARROW): Ditto.
* include/rw/_streamiter.h (_RWSTD_OPERATOR_ARROW): Ditto.
* include/rw/_tree.h (_RWSTD_OPERATOR_ARROW): Ditto.
* tests/include/alg_test.h (_RWSTD_OPERATOR_ARROW): Ditto.
* include/rw/_specialized.h (__rw_address_of): New template function
to get the address of the variable.
(uninitialized_copy): use __rw_address_of() instead of operator.
(uninitialized_fill): Ditto.
* include/tr1/_smartptr.h (operator-): return _C_ptr instead of using
operator*().
many iterator types do not work with types that implement unary operator
-
Key: STDCXX-612
URL: https://issues.apache.org/jira/browse/STDCXX-612
Project: C++ Standard Library
Issue Type: Bug
Components: 24. Iterators
Affects Versions: 4.2.0
Reporter: Travis Vitek
Assignee: Farid Zaripov
Fix For: 4.2.1
Attachments: operator_arrow.patch
Code that uses the macro _RWSTD_OPERATOR_ARROW will be affected by this
issue. Code that has '*' is also very likely to be affected.
#include deque
#include iterator
#include list
#include set
#include vector
struct S
{
void operator () const {};
};
int main ()
{
// this is just a compile test, it is not intended to run
std::reverse_iteratorS*().operator-();
std::setS::iterator().operator-();
std::dequeS::iterator().operator-();
std::listS::iterator().operator-();
return 0;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-612) many iterator types do not work with types that implement unary operator
[
https://issues.apache.org/jira/browse/STDCXX-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-612:
-
Attachment: (was: operator_arrow.patch)
many iterator types do not work with types that implement unary operator
-
Key: STDCXX-612
URL: https://issues.apache.org/jira/browse/STDCXX-612
Project: C++ Standard Library
Issue Type: Bug
Components: 24. Iterators
Affects Versions: 4.2.0
Reporter: Travis Vitek
Assignee: Farid Zaripov
Fix For: 4.2.1
Attachments: operator_arrow.patch
Code that uses the macro _RWSTD_OPERATOR_ARROW will be affected by this
issue. Code that has '*' is also very likely to be affected.
#include deque
#include iterator
#include list
#include set
#include vector
struct S
{
void operator () const {};
};
int main ()
{
// this is just a compile test, it is not intended to run
std::reverse_iteratorS*().operator-();
std::setS::iterator().operator-();
std::dequeS::iterator().operator-();
std::listS::iterator().operator-();
return 0;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-612) many iterator types do not work with types that implement unary operator
[
https://issues.apache.org/jira/browse/STDCXX-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov reassigned STDCXX-612:
Assignee: Farid Zaripov
many iterator types do not work with types that implement unary operator
-
Key: STDCXX-612
URL: https://issues.apache.org/jira/browse/STDCXX-612
Project: C++ Standard Library
Issue Type: Bug
Components: 24. Iterators
Affects Versions: 4.2.0
Reporter: Travis Vitek
Assignee: Farid Zaripov
Fix For: 4.2.1
Code that uses the macro _RWSTD_OPERATOR_ARROW will be affected by this
issue. Code that has '*' is also very likely to be affected.
#include deque
#include iterator
#include list
#include set
#include vector
struct S
{
void operator () const {};
};
int main ()
{
// this is just a compile test, it is not intended to run
std::reverse_iteratorS*().operator-();
std::setS::iterator().operator-();
std::dequeS::iterator().operator-();
std::listS::iterator().operator-();
return 0;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-612) many iterator types do not work with types that implement unary operator
[
https://issues.apache.org/jira/browse/STDCXX-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-612:
-
Attachment: operator_arrow.patch
The patch is attached
many iterator types do not work with types that implement unary operator
-
Key: STDCXX-612
URL: https://issues.apache.org/jira/browse/STDCXX-612
Project: C++ Standard Library
Issue Type: Bug
Components: 24. Iterators
Affects Versions: 4.2.0
Reporter: Travis Vitek
Assignee: Farid Zaripov
Fix For: 4.2.1
Attachments: operator_arrow.patch
Code that uses the macro _RWSTD_OPERATOR_ARROW will be affected by this
issue. Code that has '*' is also very likely to be affected.
#include deque
#include iterator
#include list
#include set
#include vector
struct S
{
void operator () const {};
};
int main ()
{
// this is just a compile test, it is not intended to run
std::reverse_iteratorS*().operator-();
std::setS::iterator().operator-();
std::dequeS::iterator().operator-();
std::listS::iterator().operator-();
return 0;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-557) Make definitions of std::terminate() consistent in all config test sources.
[ https://issues.apache.org/jira/browse/STDCXX-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov reassigned STDCXX-557: Assignee: Farid Zaripov Make definitions of std::terminate() consistent in all config test sources. --- Key: STDCXX-557 URL: https://issues.apache.org/jira/browse/STDCXX-557 Project: C++ Standard Library Issue Type: Improvement Components: Configuration Reporter: Eric Lemings Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 Attachments: terminate.patch Many of the source files for the config tests (in etc/config/src directory) contain inconsistent definitions for the std::terminate() function. Suggest making them all consistent, ideally by creating a new file with a single definition that is included where needed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-557) Make definitions of std::terminate() consistent in all config test sources.
[ https://issues.apache.org/jira/browse/STDCXX-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-557: - Attachment: terminate.patch The patch is attached. Make definitions of std::terminate() consistent in all config test sources. --- Key: STDCXX-557 URL: https://issues.apache.org/jira/browse/STDCXX-557 Project: C++ Standard Library Issue Type: Improvement Components: Configuration Reporter: Eric Lemings Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 Attachments: terminate.patch Many of the source files for the config tests (in etc/config/src directory) contain inconsistent definitions for the std::terminate() function. Suggest making them all consistent, ideally by creating a new file with a single definition that is included where needed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-557) Make definitions of std::terminate() consistent in all config test sources.
[ https://issues.apache.org/jira/browse/STDCXX-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543972 ] Farid Zaripov commented on STDCXX-557: -- 2007-11-20 Farid Zaripov [EMAIL PROTECTED] STDCXX-557 * terminate.h: New header file with a definition of the std::terminate(). * BAD_ALLOC_ASSIGNMENT.cpp (terminate): Function removed, #included terminate.h instead. * DYNAMIC_CAST.cpp: Ditto. * EXCEPTIONS.cpp: Ditto. * FLOAT.cpp: Ditto. * GLOBAL_BAD_ALLOC.cpp: Ditto. * GLOBAL_BAD_CAST.cpp: Ditto. * GLOBAL_BAD_EXCEPTION.cpp: Ditto. * GLOBAL_BAD_TYPEID.cpp: Ditto. * GLOBAL_EXCEPTION.cpp: Ditto. * GLOBAL_UNCAUGHT_EXCEPTION.cpp: Ditto. * LIB_EXCEPTIONS.cpp: Ditto. * LIMITS.cpp: Ditto. * NEW_THROWS.cpp: Ditto. * OPERATOR_DELETE_ARRAY_PLACEMENT.cpp: Ditto. * OPERATOR_DELETE_PLACEMENT.cpp: Ditto. * OPERATOR_NEW_ARRAY_PLACEMENT.cpp: Ditto. * OPERATOR_NEW_PLACEMENT.cpp: Ditto. * STD_BAD_ALLOC.cpp: Ditto. * STD_BAD_CAST.cpp: Ditto. * STD_BAD_EXCEPTION.cpp: Ditto. * STD_BAD_TYPEID.cpp: Ditto. * STD_EXCEPTION.cpp: Ditto. * STD_UNCAUGHT_EXCEPTION.cpp: Ditto. * TYPE_INFO_DTOR.cpp: Ditto. Make definitions of std::terminate() consistent in all config test sources. --- Key: STDCXX-557 URL: https://issues.apache.org/jira/browse/STDCXX-557 Project: C++ Standard Library Issue Type: Improvement Components: Configuration Reporter: Eric Lemings Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 Attachments: terminate.patch Many of the source files for the config tests (in etc/config/src directory) contain inconsistent definitions for the std::terminate() function. Suggest making them all consistent, ideally by creating a new file with a single definition that is included where needed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-558) Remove unnecessary includes of config.h in source files for config tests
[ https://issues.apache.org/jira/browse/STDCXX-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov reassigned STDCXX-558: Assignee: Farid Zaripov Remove unnecessary includes of config.h in source files for config tests -- Key: STDCXX-558 URL: https://issues.apache.org/jira/browse/STDCXX-558 Project: C++ Standard Library Issue Type: Improvement Components: Configuration Reporter: Eric Lemings Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 Several config tests in the etc/config/src directory unnecessarily include the config.h header. Need to review each source file that includes this header and remove the directive if it is not really needed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-226) __rw::__rw_new_capacity() uses floating point math
[ https://issues.apache.org/jira/browse/STDCXX-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543588 ] Farid Zaripov commented on STDCXX-226: -- We can replace _RWSTD_RATIO_DIVIDER == 1000 to 1024 and then replace division to shift. I've attached the second patch. __rw::__rw_new_capacity() uses floating point math -- Key: STDCXX-226 URL: https://issues.apache.org/jira/browse/STDCXX-226 Project: C++ Standard Library Issue Type: Improvement Components: 23. Containers Affects Versions: 4.1.2, 4.1.3 Environment: all Reporter: Martin Sebor Assignee: Farid Zaripov Attachments: new_capacity.patch Moved from the Rogue Wave bug tracking database: Created By: sebor @ May 09, 2002 11:15:41 AM The template __rw_new_capacity() uses floating point arithmetic which may be less efficient than integer arithmetic on some architectures. Need to change to integer arithmetic and correctly handle integer overflow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-226) __rw::__rw_new_capacity() uses floating point math
[ https://issues.apache.org/jira/browse/STDCXX-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-226: - Attachment: (was: new_capacity.patch) __rw::__rw_new_capacity() uses floating point math -- Key: STDCXX-226 URL: https://issues.apache.org/jira/browse/STDCXX-226 Project: C++ Standard Library Issue Type: Improvement Components: 23. Containers Affects Versions: 4.1.2, 4.1.3 Environment: all Reporter: Martin Sebor Assignee: Farid Zaripov Attachments: new_capacity.patch Moved from the Rogue Wave bug tracking database: Created By: sebor @ May 09, 2002 11:15:41 AM The template __rw_new_capacity() uses floating point arithmetic which may be less efficient than integer arithmetic on some architectures. Need to change to integer arithmetic and correctly handle integer overflow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-226) __rw::__rw_new_capacity() uses floating point math
[ https://issues.apache.org/jira/browse/STDCXX-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-226: - Attachment: new_capacity.patch __rw::__rw_new_capacity() uses floating point math -- Key: STDCXX-226 URL: https://issues.apache.org/jira/browse/STDCXX-226 Project: C++ Standard Library Issue Type: Improvement Components: 23. Containers Affects Versions: 4.1.2, 4.1.3 Environment: all Reporter: Martin Sebor Assignee: Farid Zaripov Attachments: new_capacity.patch Moved from the Rogue Wave bug tracking database: Created By: sebor @ May 09, 2002 11:15:41 AM The template __rw_new_capacity() uses floating point arithmetic which may be less efficient than integer arithmetic on some architectures. Need to change to integer arithmetic and correctly handle integer overflow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-226) __rw::__rw_new_capacity() uses floating point math
[ https://issues.apache.org/jira/browse/STDCXX-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543070 ] Farid Zaripov commented on STDCXX-226: -- I'm just thinking why the grow algorithm in basic_stringbuf::_C_grow is differ from algorithm in __rw_new_capacitybasic_string()? And what would be better: just replace floating point arithmetic to integer, or implement specialized __rw_new_capacitybasic_stringbuf()? __rw::__rw_new_capacity() uses floating point math -- Key: STDCXX-226 URL: https://issues.apache.org/jira/browse/STDCXX-226 Project: C++ Standard Library Issue Type: Improvement Components: 23. Containers Affects Versions: 4.1.2, 4.1.3 Environment: all Reporter: Martin Sebor Assignee: Farid Zaripov Attachments: new_capacity.patch Moved from the Rogue Wave bug tracking database: Created By: sebor @ May 09, 2002 11:15:41 AM The template __rw_new_capacity() uses floating point arithmetic which may be less efficient than integer arithmetic on some architectures. Need to change to integer arithmetic and correctly handle integer overflow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-321) error on std::operator==(istream_iterator, istream_iterator)
[
https://issues.apache.org/jira/browse/STDCXX-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543146
]
Farid Zaripov commented on STDCXX-321:
--
The problem is that operator==(istream_iterator, istream_iterator) calls
basic_istream::operator!(), but basic_istream::operator!() is defined in
istream header file.
So istream should be included in rw/_streamiter.h.
The similar problem in STDCXX-375.
error on std::operator==(istream_iterator, istream_iterator)
Key: STDCXX-321
URL: https://issues.apache.org/jira/browse/STDCXX-321
Project: C++ Standard Library
Issue Type: Bug
Components: 24. Iterators
Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0
Environment: All
Reporter: Martin Sebor
Fix For: 4.2.1
The well-formed program below fails to compile with both EDG eccp 3.8 and gcc
4.1.0 (I didn't try others but it's likely a bug in the library)
$ cat t.cpp make t
#include iterator
int main ()
{
std::istream_iteratorchar, char i;
(void)(i == i);
}
eccp -c -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG
-D_RWSTD_USE_CONFIG -I/build/sebor/dev/stdlib/include
-I/build/sebor/eccp-3.8-11s/include -I/build/sebor/dev/stdlib/include/ansi
-I/build/sebor/PlumHall/lvs06a/conform -I/build/sebor/PlumHall/lvs06a/dst.3
-A -x --template_directory=/build/sebor/eccp-3.8-11s/lib -g
--display_error_number --remarks --diag_suppress
193,236,340,401,261,479,487,678,679,815 --diag_suppress
177,381,191,68,550,611,997,549 t.cpp
/build/sebor/dev/stdlib/include/rw/_streamiter.h, line 124: error #349: no
operator ! matches these operands
operand types are: ! std::basic_istreamchar,
std::char_traitschar
return (__x._C_strm !!*__x._C_strm) == (__y._C_strm
!!*__y._C_strm);
^
detected during instantiation of bool std::operator==(const
std::istream_iterator_TypeT, _CharT, _Traits, _Distance
, const std::istream_iterator_TypeT, _CharT, _Traits,
_Distance ) [with _TypeT=char, _CharT=char,
_Traits=std::char_traitschar, _Distance=int] at line 6
of t.cpp
/build/sebor/dev/stdlib/include/rw/_streamiter.h, line 124: error #349: no
operator ! matches these operands
operand types are: ! std::basic_istreamchar,
std::char_traitschar
return (__x._C_strm !!*__x._C_strm) == (__y._C_strm
!!*__y._C_strm);
^
detected during instantiation of bool std::operator==(const
std::istream_iterator_TypeT, _CharT, _Traits, _Distance
, const std::istream_iterator_TypeT, _CharT, _Traits,
_Distance ) [with _TypeT=char, _CharT=char,
_Traits=std::char_traitschar, _Distance=int] at line 6
of t.cpp
2 errors detected in the compilation of t.cpp.
make: *** [t.o] Error 2
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-226) __rw::__rw_new_capacity() uses floating point math
[ https://issues.apache.org/jira/browse/STDCXX-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-226: - Attachment: new_capacity.patch The patch is attached. __rw::__rw_new_capacity() uses floating point math -- Key: STDCXX-226 URL: https://issues.apache.org/jira/browse/STDCXX-226 Project: C++ Standard Library Issue Type: Improvement Components: 23. Containers Affects Versions: 4.1.2, 4.1.3 Environment: all Reporter: Martin Sebor Assignee: Farid Zaripov Attachments: new_capacity.patch Moved from the Rogue Wave bug tracking database: Created By: sebor @ May 09, 2002 11:15:41 AM The template __rw_new_capacity() uses floating point arithmetic which may be less efficient than integer arithmetic on some architectures. Need to change to integer arithmetic and correctly handle integer overflow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-543) test suite failures due excessively long command lines
[ https://issues.apache.org/jira/browse/STDCXX-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-543: - Fix Version/s: (was: 4.2.1) 4.2.0 Fix versions reverted back to 4.2.0. Another issue STDCXX-667 created. test suite failures due excessively long command lines -- Key: STDCXX-543 URL: https://issues.apache.org/jira/browse/STDCXX-543 Project: C++ Standard Library Issue Type: Bug Components: Utilities Affects Versions: trunk Environment: Windows 2000 Reporter: Martin Sebor Assignee: Farid Zaripov Priority: Critical Fix For: 4.2.0 The test infrastructure (the exec utility to be exact) fails on platforms such as Windows 2000 that impose a low limit on the length of the command line. See the following post: http://www.nabble.com/RE%3A-Windows-build-failures-p12508639.html As Farid says in his post, to prevent such failures, excessively long command lines need to be written to a temporary file by the infrastructure and subsequently read from it by the exec utility. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-667) Change the syntax of the @filelist parameter of the exec utility to the unix style
Change the syntax of the @filelist parameter of the exec utility to the unix style -- Key: STDCXX-667 URL: https://issues.apache.org/jira/browse/STDCXX-667 Project: C++ Standard Library Issue Type: Bug Components: Utilities Affects Versions: 4.2.0 Environment: All Reporter: Farid Zaripov Priority: Minor The syntax of the command line of the exec utility (especially @filelist option) should be changed to unix style. And possibly the unix makefiles should be updated to pass the list of the executables using the external file if the resulting command line is too long. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-666) [MSVC 8-x64] 21.string.cons.cpp test fails in optimized builds due to bad codegeneration by the compiler
[MSVC 8-x64] 21.string.cons.cpp test fails in optimized builds due to bad
codegeneration by the compiler
Key: STDCXX-666
URL: https://issues.apache.org/jira/browse/STDCXX-666
Project: C++ Standard Library
Issue Type: Bug
Components: Tests
Affects Versions: 4.2.0
Environment: MSVC 8.0-x64, builds 8{d|s}, 12{d|s}
Reporter: Farid Zaripov
Fix For: 4.2.1
The 21.string.cons.cpp test fails with 16 assertions on 64-bit MSVC in
optimized builds.
The reason is the bad codegeneration in __rw_new_capacity() inlined in
std::basic_string ctors. Because of this bug the __rw_new_capacity(0, const
std::basic_string *) returns value greater that size_max() and ctor throws
exception.
The temporary workaround might be definition of the __rw_new_capacity() as
__declspec (noinline).
--
Index: include/string
===
--- include/string (revision 593511)
+++ include/string (working copy)
@@ -1528,8 +1528,13 @@
// more specialized version for basic_string; may be further specialized //
in user code for example on a user-defined allocator
+#if !defined (_WIN64) || !defined (_MSC_VER) || defined
(__INTEL_COMPILER)
template class _CharT, class _Traits, class _Allocator inline
_RWSTD_STRING_SIZE_TYPE
+#else// _WIN64 _MSC_VER !__INTEL_COMPILER
+template class _CharT, class _Traits, class _Allocator __declspec
+(noinline) _RWSTD_STRING_SIZE_TYPE
+#endif // !_WIN64 || !_MSC_VER || __INTEL_COMPILER
__rw_new_capacity (_RWSTD_STRING_SIZE_TYPE __size,
const _STD::basic_string_CharT, _Traits,
_Allocator*)
{
--
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-661) Unstable icecream.cpp example output
[ https://issues.apache.org/jira/browse/STDCXX-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-661. -- Resolution: Fixed Unstable icecream.cpp example output Key: STDCXX-661 URL: https://issues.apache.org/jira/browse/STDCXX-661 Project: C++ Standard Library Issue Type: Bug Components: Examples Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Fix For: 4.2.1 Attachments: icecream.patch The result of icecream example is different from run to run. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-661) Unstable icecream.cpp example output
Unstable icecream.cpp example output Key: STDCXX-661 URL: https://issues.apache.org/jira/browse/STDCXX-661 Project: C++ Standard Library Issue Type: Bug Components: Examples Affects Versions: 4.2.0 Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Fix For: 4.2.1 The result of icecream example is different from run to run. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-661) Unstable icecream.cpp example output
[ https://issues.apache.org/jira/browse/STDCXX-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-661: - Attachment: icecream.patch Patch attached. Unstable icecream.cpp example output Key: STDCXX-661 URL: https://issues.apache.org/jira/browse/STDCXX-661 Project: C++ Standard Library Issue Type: Bug Components: Examples Affects Versions: 4.2.0 Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Fix For: 4.2.1 Attachments: icecream.patch The result of icecream example is different from run to run. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-661) Unstable icecream.cpp example output
[ https://issues.apache.org/jira/browse/STDCXX-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-661: - Patch Info: [Patch Available] Unstable icecream.cpp example output Key: STDCXX-661 URL: https://issues.apache.org/jira/browse/STDCXX-661 Project: C++ Standard Library Issue Type: Bug Components: Examples Affects Versions: 4.2.0 Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Fix For: 4.2.1 Attachments: icecream.patch The result of icecream example is different from run to run. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-662) [MSVC 8] 17.names.cpp test fails to compile on MSVC 8 and higher
[ https://issues.apache.org/jira/browse/STDCXX-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-662: - Description: The 17.names.cpp test fails to compile due to used identifiers: a, b, c, d, i, i1, i2, s1, s2, tmp, m, f, f1, f2, p, addr, q1, d1, __nop in xmmintrin.h, fvec.h, ivec.h, dvec.h, intrin.h. (was: The 17.names.cpp test fails to compile due to used identifiers: a, b, c, d, i, i1, i2, s1, s2, tmp, m, f, f1, f2, p, addr, q1, d1, __nop, ptr in xmmintrin.h, fvec.h, ivec.h, dvec.h, intrin.h.) Assignee: Farid Zaripov [MSVC 8] 17.names.cpp test fails to compile on MSVC 8 and higher Key: STDCXX-662 URL: https://issues.apache.org/jira/browse/STDCXX-662 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.2.0 Environment: MSVC 8 and higher, ICC 9.1/Windows and higher Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 The 17.names.cpp test fails to compile due to used identifiers: a, b, c, d, i, i1, i2, s1, s2, tmp, m, f, f1, f2, p, addr, q1, d1, __nop in xmmintrin.h, fvec.h, ivec.h, dvec.h, intrin.h. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-662) [MSVC 8] 17.names.cpp test fails to compile on MSVC 8 and higher
[ https://issues.apache.org/jira/browse/STDCXX-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-662. -- Resolution: Fixed Fixed thus: http://svn.apache.org/viewvc?rev=594132view=rev Merged into trunk thus: http://svn.apache.org/viewvc?rev=594135view=rev [MSVC 8] 17.names.cpp test fails to compile on MSVC 8 and higher Key: STDCXX-662 URL: https://issues.apache.org/jira/browse/STDCXX-662 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.2.0 Environment: MSVC 8 and higher, ICC 9.1/Windows and higher Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 The 17.names.cpp test fails to compile due to used identifiers: a, b, c, d, i, i1, i2, s1, s2, tmp, m, f, f1, f2, p, addr, q1, d1, __nop in xmmintrin.h, fvec.h, ivec.h, dvec.h, intrin.h. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-663) [MSVC] MSVC declares non-standard prototype of the wcstok()
[MSVC] MSVC declares non-standard prototype of the wcstok() --- Key: STDCXX-663 URL: https://issues.apache.org/jira/browse/STDCXX-663 Project: C++ Standard Library Issue Type: Bug Components: External Environment: MSVC, ICC/Windows Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 The MSVC declares non-standard prototype of the wcstok(): wchar.h: --- _CRTIMP wchar_t * __cdecl wcstok(wchar_t *, const wchar_t *); --- Since configuration script doesn't check the correct prototype and checks only for name, the config.h file contains _RWSTD_NO_WCSTOK macro undefined. The MSVC 8 and higher declares wcstok_s() which is identical to standard wcstok(): wchar.h: --- _CRTIMP_ALTERNATIVE __checkReturn wchar_t * __cdecl wcstok_s(__inout_z_opt wchar_t * _Str, __in_z const wchar_t * _Delim, __deref_inout_z_opt wchar_t ** _Context); --- I think we need to #define _RWSTD_NO_WCSTOK macro in include/rw/_config_msvcrt.h and add inline wcstok() invoking wcstok_s() in include /ansi/cwchar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-663) [MSVC] MSVC declares non-standard prototype of the wcstok()
[ https://issues.apache.org/jira/browse/STDCXX-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-663: - Attachment: wcstok.patch The proposed patch is attached. [MSVC] MSVC declares non-standard prototype of the wcstok() --- Key: STDCXX-663 URL: https://issues.apache.org/jira/browse/STDCXX-663 Project: C++ Standard Library Issue Type: Bug Components: External Environment: MSVC, ICC/Windows Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 Attachments: wcstok.patch The MSVC declares non-standard prototype of the wcstok(): wchar.h: --- _CRTIMP wchar_t * __cdecl wcstok(wchar_t *, const wchar_t *); --- Since configuration script doesn't check the correct prototype and checks only for name, the config.h file contains _RWSTD_NO_WCSTOK macro undefined. The MSVC 8 and higher declares wcstok_s() which is identical to standard wcstok(): wchar.h: --- _CRTIMP_ALTERNATIVE __checkReturn wchar_t * __cdecl wcstok_s(__inout_z_opt wchar_t * _Str, __in_z const wchar_t * _Delim, __deref_inout_z_opt wchar_t ** _Context); --- I think we need to #define _RWSTD_NO_WCSTOK macro in include/rw/_config_msvcrt.h and add inline wcstok() invoking wcstok_s() in include /ansi/cwchar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-578) purify reports mismatched new/delete in facet implementation.
[ https://issues.apache.org/jira/browse/STDCXX-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov closed STDCXX-578. purify reports mismatched new/delete in facet implementation. - Key: STDCXX-578 URL: https://issues.apache.org/jira/browse/STDCXX-578 Project: C++ Standard Library Issue Type: Bug Components: 22. Localization Affects Versions: 4.2.0 Reporter: Travis Vitek Assignee: Travis Vitek Fix For: 4.2.1 Attachments: stdcxx-578.patch Purify instrumented ./stocks (pid 19642) FMM: Freeing mismatched memory: * This is occurring while in thread 19642: operator delete(*) [rtlib.o] __rw::__rw_facet::~__rw_facet[not-in-charge]() [facet.cpp:139] std::time_putchar, std::ostreambuf_iteratorchar, std::char_traitschar ::~time_put[not-in-charge]() [_time_put.h:105] std::time_put_bynamechar, std::ostreambuf_iteratorchar, std::char_traitschar ::~time_put_byname[in-charge deleting]() [ti_time_put.cpp:105] __rw::__rw_facet::_C_manage(__rw::__rw_facet*, __rw::__rw_facet::_C_facet_type, char const*, __rw::__rw_facet* (*)(unsigned, char const*)) [facet.cpp:427] __rw::__rw_locale::~__rw_locale[in-charge]() [locale_body.cpp:692] * Attempting to free block at 0x80f3fe0 in the heap. * Address 0x80f3fe0 is at the beginning of a malloc'd block of 2452 bytes. * This block was allocated from thread -1207973632: malloc [rtlib.o] operator new(unsigned) [libstd15d.so] operator new [](unsigned) [libstd15d.so] __rw::__rw_get_timepunct(__rw::__rw_facet const*, int, unsigned) [time_put.cpp:454] __rw::__rw_get_time_put_data(__rw::__rw_time_put_data, __rw::__rw_facet const*, tm const*, char, char, bool) [time_put.cpp:2115] __rw::__rw_put_time(__rw::__rw_facet const*, char*, unsigned, std::ios_base, char, tm const*, char, char, int, int) [time_put.cpp:2666] * This block of memory was obtained using an allocation routine which is not compatible with the routine by which it is being freed. Memory is allocated with array new, but deallocated with operator delete. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-578) purify reports mismatched new/delete in facet implementation.
[ https://issues.apache.org/jira/browse/STDCXX-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-578. -- Resolution: Fixed purify reports mismatched new/delete in facet implementation. - Key: STDCXX-578 URL: https://issues.apache.org/jira/browse/STDCXX-578 Project: C++ Standard Library Issue Type: Bug Components: 22. Localization Affects Versions: 4.2.0 Reporter: Travis Vitek Assignee: Travis Vitek Fix For: 4.2.1 Attachments: stdcxx-578.patch Purify instrumented ./stocks (pid 19642) FMM: Freeing mismatched memory: * This is occurring while in thread 19642: operator delete(*) [rtlib.o] __rw::__rw_facet::~__rw_facet[not-in-charge]() [facet.cpp:139] std::time_putchar, std::ostreambuf_iteratorchar, std::char_traitschar ::~time_put[not-in-charge]() [_time_put.h:105] std::time_put_bynamechar, std::ostreambuf_iteratorchar, std::char_traitschar ::~time_put_byname[in-charge deleting]() [ti_time_put.cpp:105] __rw::__rw_facet::_C_manage(__rw::__rw_facet*, __rw::__rw_facet::_C_facet_type, char const*, __rw::__rw_facet* (*)(unsigned, char const*)) [facet.cpp:427] __rw::__rw_locale::~__rw_locale[in-charge]() [locale_body.cpp:692] * Attempting to free block at 0x80f3fe0 in the heap. * Address 0x80f3fe0 is at the beginning of a malloc'd block of 2452 bytes. * This block was allocated from thread -1207973632: malloc [rtlib.o] operator new(unsigned) [libstd15d.so] operator new [](unsigned) [libstd15d.so] __rw::__rw_get_timepunct(__rw::__rw_facet const*, int, unsigned) [time_put.cpp:454] __rw::__rw_get_time_put_data(__rw::__rw_time_put_data, __rw::__rw_facet const*, tm const*, char, char, bool) [time_put.cpp:2115] __rw::__rw_put_time(__rw::__rw_facet const*, char*, unsigned, std::ios_base, char, tm const*, char, char, int, int) [time_put.cpp:2666] * This block of memory was obtained using an allocation routine which is not compatible with the routine by which it is being freed. Memory is allocated with array new, but deallocated with operator delete. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-619) purify reports array bounds read error in 25.remove test
[ https://issues.apache.org/jira/browse/STDCXX-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-619. -- Resolution: Fixed purify reports array bounds read error in 25.remove test Key: STDCXX-619 URL: https://issues.apache.org/jira/browse/STDCXX-619 Project: C++ Standard Library Issue Type: Improvement Components: Tests Affects Versions: 4.2.0 Reporter: Travis Vitek Assignee: Travis Vitek Priority: Minor Fix For: 4.2.1 Attachments: stdcxx-619.patch An rw_assert indexes past the end of an array if the preceeding for loop does not experience a failure. Purify instrumented ./25.remove (pid 19671) ABR: Array bounds read: * This is occurring while in thread 19671: test_removeFwdIterUserClass, UserClass, EqualityPredicateUserClass (int, char const*, char, unsigned, FwdIterUserClass, NoIterator, UserClass const*, UserClass const*, RemoveTag) [25.remove.cpp:213] test_removeFwdIterUserClass, NoIterator, UserClass, EqualityPredicateUserClass, RemoveTag (FwdIterUserClass, UserClass, NoIterator const*, UserClass const*, EqualityPredicateUserClass) [25.remove.cpp:384] test_removeUserClass, EqualityPredicateUserClass, RemoveTag (UserClass const*, EqualityPredicateUserClass const*, UserClass) [25.remove.cpp:440] test_removeUserClass(UserClass const*) [25.remove.cpp:471] run_test(int, char**) [25.remove.cpp:590] *unknown func* [pc=0x81201a8] * Reading 4 bytes from 0x81b88f8 in the heap. * Address 0x81b88f8 is 5 bytes past end of a malloc'd block at 0x81b88c0 of 52 bytes. * This block was allocated from thread -1207973632: malloc [rtlib.o] operator new(unsigned) [libstd15d.so] operator new [](unsigned) [libstd15d.so] UserClass* __rw_from_charUserClass(UserClass*, char const*, unsigned, bool) [value.cpp:485] UserClass::from_char(char const*, unsigned, bool) [value.cpp:533] test_removeFwdIterUserClass, UserClass, EqualityPredicateUserClass (int, char const*, char, unsigned, FwdIterUserClass, NoIterator, UserClass const*, UserClass const*, RemoveTag) [25.remove.cpp:153] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-601) purify reports uninitialized memory read in 20.auto.ptr test
[ https://issues.apache.org/jira/browse/STDCXX-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-601. -- Resolution: Fixed purify reports uninitialized memory read in 20.auto.ptr test - Key: STDCXX-601 URL: https://issues.apache.org/jira/browse/STDCXX-601 Project: C++ Standard Library Issue Type: Improvement Components: Tests Affects Versions: 4.2.0 Reporter: Travis Vitek Assignee: Travis Vitek Priority: Minor Fix For: 4.2.1 Attachments: 20.auto.ptr.log, stdcxx-601.patch Allocated object is not initialized but the contents of pointers to it are dereferenced, resulting in a purify UMR error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-619) purify reports array bounds read error in 25.remove test
[ https://issues.apache.org/jira/browse/STDCXX-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov closed STDCXX-619. purify reports array bounds read error in 25.remove test Key: STDCXX-619 URL: https://issues.apache.org/jira/browse/STDCXX-619 Project: C++ Standard Library Issue Type: Improvement Components: Tests Affects Versions: 4.2.0 Reporter: Travis Vitek Assignee: Travis Vitek Priority: Minor Fix For: 4.2.1 Attachments: stdcxx-619.patch An rw_assert indexes past the end of an array if the preceeding for loop does not experience a failure. Purify instrumented ./25.remove (pid 19671) ABR: Array bounds read: * This is occurring while in thread 19671: test_removeFwdIterUserClass, UserClass, EqualityPredicateUserClass (int, char const*, char, unsigned, FwdIterUserClass, NoIterator, UserClass const*, UserClass const*, RemoveTag) [25.remove.cpp:213] test_removeFwdIterUserClass, NoIterator, UserClass, EqualityPredicateUserClass, RemoveTag (FwdIterUserClass, UserClass, NoIterator const*, UserClass const*, EqualityPredicateUserClass) [25.remove.cpp:384] test_removeUserClass, EqualityPredicateUserClass, RemoveTag (UserClass const*, EqualityPredicateUserClass const*, UserClass) [25.remove.cpp:440] test_removeUserClass(UserClass const*) [25.remove.cpp:471] run_test(int, char**) [25.remove.cpp:590] *unknown func* [pc=0x81201a8] * Reading 4 bytes from 0x81b88f8 in the heap. * Address 0x81b88f8 is 5 bytes past end of a malloc'd block at 0x81b88c0 of 52 bytes. * This block was allocated from thread -1207973632: malloc [rtlib.o] operator new(unsigned) [libstd15d.so] operator new [](unsigned) [libstd15d.so] UserClass* __rw_from_charUserClass(UserClass*, char const*, unsigned, bool) [value.cpp:485] UserClass::from_char(char const*, unsigned, bool) [value.cpp:533] test_removeFwdIterUserClass, UserClass, EqualityPredicateUserClass (int, char const*, char, unsigned, FwdIterUserClass, NoIterator, UserClass const*, UserClass const*, RemoveTag) [25.remove.cpp:153] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-596) purify reports uninitialized memory read in _rw_fmtarray
[ https://issues.apache.org/jira/browse/STDCXX-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-596. -- Resolution: Fixed purify reports uninitialized memory read in _rw_fmtarray Key: STDCXX-596 URL: https://issues.apache.org/jira/browse/STDCXX-596 Project: C++ Standard Library Issue Type: Improvement Components: Test Driver Affects Versions: 4.2.0 Reporter: Travis Vitek Assignee: Travis Vitek Priority: Minor Fix For: 4.2.1 Attachments: stdcxx-596.patch UMR: Uninitialized memory read: * This is occurring while in thread 26262: int _rw_fmtarraychar(FmtSpec const, Buffer, char const*, unsigned, int) [printf.cpp:2012] _rw_fmtstr(FmtSpec const, Buffer, char const*, unsigned) [printf.cpp:2373] _rw_fmtllong(FmtSpec const, Buffer, long long) [printf.cpp:1220] int rw_fmtintegerlong long(FmtSpec const, Buffer, long long) [printf.cpp:1237] _rw_fmtinteger(FmtSpec*, unsigned, Buffer, VarArgs*) [printf.cpp:1287] _rw_vasnprintf_c99(FmtSpec*, unsigned, Buffer, VarArgs*) [printf.cpp:540] * Reading 1 byte from 0xbfffe9f4 on the stack of thread 26262. * Address 0xbfffe9f4 is 28 bytes past start of local variable buffer in function _rw_fmtllong(FmtSpec const, Buffer, long long). Purify instrumented ./18_ilimits (pid 26262) UMR: Uninitialized memory read: * This is occurring while in thread 26262: int _rw_fmtarraychar(FmtSpec const, Buffer, char const*, unsigned, int) [printf.cpp:2012] _rw_fmtstr(FmtSpec const, Buffer, char const*, unsigned) [printf.cpp:2373] _rw_fmtllong(FmtSpec const, Buffer, long long) [printf.cpp:1220] int rw_fmtintegerunsigned long long(FmtSpec const, Buffer, unsigned long long) [printf.cpp:1237] _rw_fmtinteger(FmtSpec*, unsigned, Buffer, VarArgs*) [printf.cpp:1370] _rw_vasnprintf_c99(FmtSpec*, unsigned, Buffer, VarArgs*) [printf.cpp:540] * Reading 1 byte from 0xbfffe9e1 on the stack of thread 26262. * Address 0xbfffe9e1 is9 bytes past start of local variable buffer in function _rw_fmtllong(FmtSpec const, Buffer, long long). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-601) purify reports uninitialized memory read in 20.auto.ptr test
[ https://issues.apache.org/jira/browse/STDCXX-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov closed STDCXX-601. purify reports uninitialized memory read in 20.auto.ptr test - Key: STDCXX-601 URL: https://issues.apache.org/jira/browse/STDCXX-601 Project: C++ Standard Library Issue Type: Improvement Components: Tests Affects Versions: 4.2.0 Reporter: Travis Vitek Assignee: Travis Vitek Priority: Minor Fix For: 4.2.1 Attachments: 20.auto.ptr.log, stdcxx-601.patch Allocated object is not initialized but the contents of pointers to it are dereferenced, resulting in a purify UMR error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-596) purify reports uninitialized memory read in _rw_fmtarray
[ https://issues.apache.org/jira/browse/STDCXX-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov closed STDCXX-596. purify reports uninitialized memory read in _rw_fmtarray Key: STDCXX-596 URL: https://issues.apache.org/jira/browse/STDCXX-596 Project: C++ Standard Library Issue Type: Improvement Components: Test Driver Affects Versions: 4.2.0 Reporter: Travis Vitek Assignee: Travis Vitek Priority: Minor Fix For: 4.2.1 Attachments: stdcxx-596.patch UMR: Uninitialized memory read: * This is occurring while in thread 26262: int _rw_fmtarraychar(FmtSpec const, Buffer, char const*, unsigned, int) [printf.cpp:2012] _rw_fmtstr(FmtSpec const, Buffer, char const*, unsigned) [printf.cpp:2373] _rw_fmtllong(FmtSpec const, Buffer, long long) [printf.cpp:1220] int rw_fmtintegerlong long(FmtSpec const, Buffer, long long) [printf.cpp:1237] _rw_fmtinteger(FmtSpec*, unsigned, Buffer, VarArgs*) [printf.cpp:1287] _rw_vasnprintf_c99(FmtSpec*, unsigned, Buffer, VarArgs*) [printf.cpp:540] * Reading 1 byte from 0xbfffe9f4 on the stack of thread 26262. * Address 0xbfffe9f4 is 28 bytes past start of local variable buffer in function _rw_fmtllong(FmtSpec const, Buffer, long long). Purify instrumented ./18_ilimits (pid 26262) UMR: Uninitialized memory read: * This is occurring while in thread 26262: int _rw_fmtarraychar(FmtSpec const, Buffer, char const*, unsigned, int) [printf.cpp:2012] _rw_fmtstr(FmtSpec const, Buffer, char const*, unsigned) [printf.cpp:2373] _rw_fmtllong(FmtSpec const, Buffer, long long) [printf.cpp:1220] int rw_fmtintegerunsigned long long(FmtSpec const, Buffer, unsigned long long) [printf.cpp:1237] _rw_fmtinteger(FmtSpec*, unsigned, Buffer, VarArgs*) [printf.cpp:1370] _rw_vasnprintf_c99(FmtSpec*, unsigned, Buffer, VarArgs*) [printf.cpp:540] * Reading 1 byte from 0xbfffe9e1 on the stack of thread 26262. * Address 0xbfffe9e1 is9 bytes past start of local variable buffer in function _rw_fmtllong(FmtSpec const, Buffer, long long). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-593) purify reports array bounds write error from rw_locales in 22.locale.cons.stdcxx-485 test
[ https://issues.apache.org/jira/browse/STDCXX-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov closed STDCXX-593. purify reports array bounds write error from rw_locales in 22.locale.cons.stdcxx-485 test - Key: STDCXX-593 URL: https://issues.apache.org/jira/browse/STDCXX-593 Project: C++ Standard Library Issue Type: Improvement Components: Test Driver Affects Versions: 4.2.0 Reporter: Travis Vitek Assignee: Travis Vitek Priority: Minor Fix For: 4.2.1 Attachments: stdcxx-593.patch When prepending the default locale to the locale name array, the size of the resulting string is not modified, so later write operations can write past the end of the buffer. Purify instrumented ./22.locale.cons.stdcxx-485 (pid 13090) ABW: Array bounds write: * This is occurring while in thread 13090: strcpy [rtlib.o] rw_locales(int, char const*, bool) [locale.cpp:486] run_test(int, char**) [22.locale.cons.stdcxx-485.cpp:41] *unknown func* [pc=0x808b380] rw_test(int, char**, char const*, char const*, char const*, int (*)(int, char**)) [driver.cpp:1128] main [22.locale.cons.stdcxx-485.cpp:78] * Writing 7 bytes to 0x810d72a in the heap (1 byte at 0x810d730 illegal). * Address 0x810d72a is 5114 bytes into a malloc'd block at 0x810c330 of 5120 bytes. * This block was allocated from thread -1207973632: malloc [rtlib.o] rw_locales(int, char const*, bool) [locale.cpp:350] run_test(int, char**) [22.locale.cons.stdcxx-485.cpp:41] *unknown func* [pc=0x808b380] rw_test(int, char**, char const*, char const*, char const*, int (*)(int, char**)) [driver.cpp:1128] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-584) purify reports memory leak from __rw_vfmtwhat in 18.exception test
[ https://issues.apache.org/jira/browse/STDCXX-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-584. -- Resolution: Fixed purify reports memory leak from __rw_vfmtwhat in 18.exception test -- Key: STDCXX-584 URL: https://issues.apache.org/jira/browse/STDCXX-584 Project: C++ Standard Library Issue Type: Improvement Components: Tests Affects Versions: 4.2.0 Reporter: Travis Vitek Assignee: Travis Vitek Priority: Trivial Fix For: 4.2.1 Attachments: stdcxx-584.patch The library uses a system of functions for platforms that don't support exceptions. The __rw_throw function calls __rw_vfmtwhat() to get a string describing the exception that has occured. Under some conditions the string is allocated from the heap as an array of characters. Eventually __rw_throw invokes a function via pointer (__rw_throw_proc) that is supposed to process the exception (possibly by throwing a real exception object). Unfortunately the test does not deallocate the string that was allocated by __rw_vfmtwhat(). Purify: Searching for all memory leaks... Memory leaked: 3072 bytes (25.6%); potentially leaked: 0 bytes (0%) wLK: 3072 bytes leaked in 12 blocks * This memory was allocated from: malloc [rtlib.o] operator new(unsigned) [libstd15d.so] operator new [](unsigned) [libstd15d.so] __rw::__rw_vfmtwhat(char*, unsigned, char const*, char*) [exception.cpp:479] __rw::__rw_throw(int, ...) [exception.cpp:825] test_rw_throw() [18.exception.cpp:527] * Block of 256 bytes (12 times); last block at 0x8118de0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-587) purify reports memory leak from __rw_tmpbuf in 20.temp.buffer.mt
[ https://issues.apache.org/jira/browse/STDCXX-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-587. -- Resolution: Fixed purify reports memory leak from __rw_tmpbuf in 20.temp.buffer.mt Key: STDCXX-587 URL: https://issues.apache.org/jira/browse/STDCXX-587 Project: C++ Standard Library Issue Type: Improvement Components: Tests Affects Versions: 4.2.0 Reporter: Travis Vitek Assignee: Travis Vitek Priority: Minor Fix For: 4.2.1 Attachments: stdcxx-587.patch Each test thread iterates some number of times switching on a counter. If the last iteration runs one of the allocation functions, the temporary buffer will not be deallocated when the thread exits. Purify: Searching for all memory leaks... Memory leaked: 42 bytes (6.98%); potentially leaked: 0 bytes (0%) MLK: 24 bytes leaked at 0x81089d0 * This memory was allocated from: malloc [rtlib.o] operator new(unsigned) [libstd15d.so] __rw::__rw_allocate(unsigned, int) [memory.cpp:53] __rw_tmpbuf[tmpbuf.cpp:115] std::pairlong long*, int std::get_temporary_bufferlong long, int (int, long long*) [_rawiter.h:138] std::pairlong long*, int std::get_temporary_bufferlong long(int) [_rawiter.h:153] MLK: 18 bytes leaked at 0x8108a38 * This memory was allocated from: malloc [rtlib.o] operator new(unsigned) [libstd15d.so] __rw::__rw_allocate(unsigned, int) [memory.cpp:53] __rw_tmpbuf[tmpbuf.cpp:115] std::pairshort*, int std::get_temporary_buffershort, int (int, short*) [_rawiter.h:138] std::pairshort*, int std::get_temporary_buffershort(int) [_rawiter.h:153] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
