RE: svn commit: r596354 - /incubator/stdcxx/trunk/tests/utilities/20.auto.ptr.cpp
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Monday, November 19, 2007 11:27 PM To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r596354 - /incubator/stdcxx/trunk/tests/utilities/20.auto.ptr.cpp [EMAIL PROTECTED] wrote: Author: faridz Date: Mon Nov 19 08:20:27 2007 New Revision: 596354 URL: http://svn.apache.org/viewvc?rev=596354view=rev Log: 2007-11-19 Farid Zaripov [EMAIL PROTECTED] * 20.auto.ptr.cpp (test_auto_ptr): Worked around bug in MSVC 7.x. Which one? Details please... https://issues.apache.org/jira/browse/STDCXX-669 Farid.
[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
RE: [PATCH] 22.locale.ctype.is.cpp
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Monday, November 19, 2007 8:30 PM To: stdcxx-dev@incubator.apache.org Subject: Re: [PATCH] 22.locale.ctype.is.cpp Martin Sebor wrote: Seems reasonable. We should also guard the calls to the the wchar_t specializations of the function with _RWSTD_NO_WCHAR_T. On second thought, isn't there a more robust way of fixing this, one that makes it work regardless of the order of the calls to the function? E.g., have the function that needs the environment variable defined always define it and the one that needs it undefined always undefine it? The environment variable is defined in rw_create_locale() by invoking rw_set_locale_root (). But rw_create_locale() designed to set environment variable and exec localedef utility only once. But we can save the variable value in test_libc(), then undefine it and restore the value at the end of the function. Farid.
[PATCH] MSVC has non-standard prototype of the wcstok()
The all MSVC has the non-standard prototype of the wcstok():
wchar_t* wcstok(wchar_t*, const wchar_t*);
The prototype from C standard:
wchar_t* wcstok(wchar_t*, const wchar_t*, wchar_t**);
Since the configure script performs checking only names and doesn't
checking the correct prototype, the _RWSTD_NO_WCSTOK macro is
not defined in config.h. As a result the 21.cwchar.cpp test asserts on
wcstok() not declared.
However the MSVC 8 and later has the wcstok_s() function with the
prototype similar to the standard wcstok():
wchar_t* wcstok_s(wchar_t* _Str, const wchar_t* _Delim, wchar_t **
_Context);
I've propose the following changes:
ChangeLog:
* rw/_config_msvcrt.h: #define _RWSTD_NO_WCSTOK and
_RWSTD_NO_WCSTOK_IN_LIBC
macros since the MSVC has the non-standard prototype of the wcstok().
* ansi/cwchar [_MSC_VER = 1400]: Define inline wcstok() function
using wcstok_s().
#undefine _RWSTD_NO_WCSTOK and _RWSTD_NO_WCSTOK_IN_LIBC macros.
Index: include/ansi/cwchar
===
--- include/ansi/cwchar (revision 596338)
+++ include/ansi/cwchar (working copy)
@@ -1074,6 +1074,22 @@
using ::wcstok;
# undef _RWSTD_NO_WCSTOK
+#elif defined (_MSC_VER) 1400 = _MSC_VER
+
+} // namespace std
+
+/* extern C++ */ inline wchar_t*
+wcstok (wchar_t* __s1, const wchar_t* __s2, wchar_t** __ptr)
+{
+return wcstok_s (__s1, __s2, __ptr);
+}
+
+namespace std {
+
+using ::wcstok;
+
+# undef _RWSTD_NO_WCSTOK
+# undef _RWSTD_NO_WCSTOK_IN_LIBC
#endif // _RWSTD_NO_WCSTOK[_IN_LIBC]
#ifndef _RWSTD_NO_WCSTOL
Index: include/rw/_config-msvcrt.h
===
--- include/rw/_config-msvcrt.h (revision 596338)
+++ include/rw/_config-msvcrt.h (working copy)
@@ -54,6 +54,15 @@
# define _RWSTD_NO_DEPRECATED_C_HEADERS
#endif // _RWSTD_NO_DEPRECATED_C_HEADERS
+#ifndef _RWSTD_NO_WCSTOK
+// MSVC CRT has incorrect prototype of the wcstok()
+# define _RWSTD_NO_WCSTOK
+#endif // _RWSTD_NO_WCSTOK
+
+#ifndef _RWSTD_NO_WCSTOK_IN_LIBC
+# define _RWSTD_NO_WCSTOK_IN_LIBC
+#endif // _RWSTD_NO_WCSTOK_IN_LIBC
+
// operator new and delete is not reliably replaceable across
// shared library boundaries, which includes the shared library
// version of the language support library
Farid.
Re: [PATCH] 22.locale.ctype.is.cpp
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Monday, November 19, 2007 8:30 PM To: stdcxx-dev@incubator.apache.org Subject: Re: [PATCH] 22.locale.ctype.is.cpp Martin Sebor wrote: Seems reasonable. We should also guard the calls to the the wchar_t specializations of the function with _RWSTD_NO_WCHAR_T. On second thought, isn't there a more robust way of fixing this, one that makes it work regardless of the order of the calls to the function? E.g., have the function that needs the environment variable defined always define it and the one that needs it undefined always undefine it? The environment variable is defined in rw_create_locale() by invoking rw_set_locale_root (). But rw_create_locale() designed to set environment variable and exec localedef utility only once. That sounds like a design limitation of rw_create_locale(), don't you think? It seems there should be a way to switch back to the libc locale implementation... But we can save the variable value in test_libc(), then undefine it and restore the value at the end of the function. ...such as this :) I guess this would work. Although I'm not sure I'm completely comfortable with this approach either. It seems that the functions shouldn't have to worry about these details (i.e., that some other functions might have switched things around underneath them before they were called). They should just work :) Maybe we should just document the current behavior and be done with it. It's your call. Martin
[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] 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_12543962
]
Travis Vitek commented on STDCXX-612:
-
The following change to tr1/_smartptr.h removes an assertion that _C_ptr is
valid. I don't know if the assert was necessary in the first place, but it
probably shouldn't be removed without reason.
element_type* operator-() const {
-return **this;
+return _C_ptr;
}
Also, I think the _RWSTD_ADDRESS_OF() would be easy to accidentally misuse.
_RWSTD_ADDRESS_OF (int, i); // cast address of i to an int
Wouldn't it make more sense for __rw_address_of to do the heavy lifting, and to
write the macro to call through? That would remove requirement for the first
parameter, which would cleanup the code just a little bit. It might also be a
good idea to add an overload of __rw_address_of for const references.
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] Issue Comment Edited: (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_12543962
]
vitek edited comment on STDCXX-612 at 11/20/07 9:36 AM:
---
The change to tr1/_smartptr.h removes an assertion that _C_ptr is valid. I
don't know if the assert was necessary in the first place, but it probably
shouldn't be removed without reason.
Also, I think the _RWSTD_ADDRESS_OF() would be easy to accidentally misuse.
_RWSTD_ADDRESS_OF (int, i); // cast address of i to an int
Wouldn't it make more sense for __rw_address_of to do the heavy lifting, and to
write the macro to call through? That would require the free function be moved
to rw/_defs.h which might not be ideal. It has the advantage that would remove
requirement for the first macro parameter, which would cleanup the code just a
little bit. It might also be a good idea to add an overload of __rw_address_of
for const references.
was (Author: vitek):
The following change to tr1/_smartptr.h removes an assertion that _C_ptr is
valid. I don't know if the assert was necessary in the first place, but it
probably shouldn't be removed without reason.
element_type* operator-() const {
-return **this;
+return _C_ptr;
}
Also, I think the _RWSTD_ADDRESS_OF() would be easy to accidentally misuse.
_RWSTD_ADDRESS_OF (int, i); // cast address of i to an int
Wouldn't it make more sense for __rw_address_of to do the heavy lifting, and to
write the macro to call through? That would remove requirement for the first
parameter, which would cleanup the code just a little bit. It might also be a
good idea to add an overload of __rw_address_of for const references.
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-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-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_12543996
]
Travis Vitek commented on STDCXX-612:
-
Also, some places in the standard have `Returns' and `Effects' clauses that say
that the operator-() is supposed to return some specific thing. For example,
24.4.1.3.4 [revers.iter.opref] has an effects clause that claims `pointer
operator-() const' returns (operator*()). Of course, with that said, there is
nothing that says how container iterators should behave when this situation
comes up for their forward iterators. It seems to indicate that the containers
should use reverse_iterator for their reverse iterator implementation, which,
as mentioned above, is essentially required to not work with types that
implement operator to do something abnormal.
If we make some of these changes it will make our implementation non-compliant,
which may be a bad thing. This is one of those issues where it might need to be
brought up with the committee for discussion before we have a complete and
satisfying solution. Of course the standards committee might have already
covered this issue at one point, but if they have, they haven't documented it
very well.
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-607) [IBM XLC++ 9.0/AIX 5.3] SIGHUP in 22.locale.messages
[ https://issues.apache.org/jira/browse/STDCXX-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-607: Attachment: stdcxx-607.patch Note that this issue causes hangs on Linux, AIX and IRIX. I'm attaching a patch that appears to fix this problem and was verified on IRIX and AIX. 2007-11-20 Travis Vitek [EMAIL PROTECTED] STDCXX-607 * locale.cpp (__rw_cat_close): Put lock guard into local scope to avoid recursive acquire on error. [IBM XLC++ 9.0/AIX 5.3] SIGHUP in 22.locale.messages Key: STDCXX-607 URL: https://issues.apache.org/jira/browse/STDCXX-607 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.2.0 Environment: IBM XLC++ 9.0/AIX 5.3 Reporter: Martin Sebor Assignee: Travis Vitek Fix For: 4.2.1 Attachments: stdcxx-607.patch When compiled with IBM XLC++ 9.0 on AIX 5.3, the test 22.locale.messages seems to hang. The following line has been copied from a 12a log on the latest trunk: 22.locale.messagesHUP0 0.030 1.190 300.080 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-607) [IBM XLC++ 9.0/AIX 5.3] SIGHUP in 22.locale.messages
[ https://issues.apache.org/jira/browse/STDCXX-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-607: Patch Info: [Patch Available] Environment: IBM XLC++ 9.0/AIX 5.3, LINUX, IRIX (was: IBM XLC++ 9.0/AIX 5.3) [IBM XLC++ 9.0/AIX 5.3] SIGHUP in 22.locale.messages Key: STDCXX-607 URL: https://issues.apache.org/jira/browse/STDCXX-607 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.2.0 Environment: IBM XLC++ 9.0/AIX 5.3, LINUX, IRIX Reporter: Martin Sebor Assignee: Travis Vitek Fix For: 4.2.1 Attachments: stdcxx-607.patch When compiled with IBM XLC++ 9.0 on AIX 5.3, the test 22.locale.messages seems to hang. The following line has been copied from a 12a log on the latest trunk: 22.locale.messagesHUP0 0.030 1.190 300.080 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
