[jira] Created: (STDCXX-564) [MSVC] 64-bit conversion warnings building the library
[MSVC] 64-bit conversion warnings building the library -- Key: STDCXX-564 URL: https://issues.apache.org/jira/browse/STDCXX-564 Project: C++ Standard Library Issue Type: Bug Components: Build Affects Versions: trunk Environment: MSVC 8.0 x64 platform Reporter: Farid Zaripov Fix For: 4.2 These warnings I got when building the library with MSVC 8.0 / x64 platform: file.cpp $(TOPDIR)\src\file.cpp(484) : warning C4244: 'argument' : conversion from '__int64' to 'long', possible loss of data $(TOPDIR)\src\file.cpp(493) : warning C4244: 'argument' : conversion from '__int64' to 'long', possible loss of data $(TOPDIR)\src\file.cpp(508) : warning C4244: 'argument' : conversion from 'unsigned __int64' to 'unsigned int', possible loss of data $(TOPDIR)\src\file.cpp(523) : warning C4244: 'argument' : conversion from 'unsigned __int64' to 'unsigned int', possible loss of data locale_core.cpp $(TOPDIR)\src\locale_core.cpp(141) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data num_put.cpp $(TOPDIR)\src\num_put.cpp(745) : warning C4244: 'argument' : conversion from '__int64' to 'int', possible loss of data $(TOPDIR)\src\num_put.cpp(772) : warning C4244: 'argument' : conversion from '__int64' to 'int', possible loss of data $(TOPDIR)\src\num_put.cpp(802) : warning C4244: 'argument' : conversion from '__int64' to 'int', possible loss of data $(TOPDIR)\src\num_put.cpp(830) : warning C4244: 'argument' : conversion from '__int64' to 'int', possible loss of data ti_num_get.cpp $(TOPDIR)\include\loc/_punct.cc(90) : warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) $(TOPDIR)\include\loc/_punct.h(143) : see reference to function template instantiation '__rw::__rw_istreambuf_iterator __rw::__rw_match_name>(std::istreambuf_iterator<_CharT,_Traits>,std::istreambuf_iterator<_CharT,_Traits>,const char *const *,const unsigned __int64 *,unsigned __int64,unsigned __int64 &,int &,std::ios_base *)' being compiled with [ _CharT=char, _Traits=std::char_traits ] ti_wnum_get.cpp $(TOPDIR)\include\loc/_punct.cc(90) : warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) $(TOPDIR)\include\loc/_punct.h(150) : see reference to function template instantiation '__rw::__rw_wistreambuf_iterator __rw::__rw_match_name>(std::istreambuf_iterator<_CharT,_Traits>,std::istreambuf_iterator<_CharT,_Traits>,const wchar_t *const *,const unsigned __int64 *,unsigned __int64,unsigned __int64 &,int &,std::ios_base *)' being compiled with [ _CharT=wchar_t, _Traits=std::char_traits ] $(TOPDIR)\include\loc/_punct.cc(90) : warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) $(TOPDIR)\include\loc/_num_get.cc(218) : see reference to function template instantiation '_InputIter __rw::__rw_match_name>(_InputIter,_InputIter,const _CharT *const *,const unsigned __int64 *,unsigned __int64,unsigned __int64 &,int &,std::ios_base *)' being compiled with [ _InputIter=std::istreambuf_iterator>, _CharT=char, _Traits=std::char_traits ] $(TOPDIR)\include\loc/_num_get.cc(172) : while compiling class template member function 'std::istreambuf_iterator<_CharT,_Traits> std::num_get<_CharT,_InputIter>::do_get(std::istreambuf_iterator<_CharT,_Traits>,std::istreambuf_iterator<_CharT,_Traits>,std::ios_base &,__rw::__rw_iostate &,bool &) const' with [ _CharT=char, _Traits=std::char_traits, _InputIter=std::istreambuf_iterator> ] $(TOPDIR)\include\loc/_locale.h(346) : see reference to class template instantiation 'std::num_get<_CharT,_InputIter>' being compiled with [ _CharT=char, _InputIter=std::istreambuf_iterator> ] $(TOPDIR)\include\loc/_locale.h(88) : see reference to function template instantiation 'const __rw::__rw_facet *__rw::__rw_get_facet<_Facet>(const std::locale &,const _Facet *)' being compiled with [ _Facet=std::numpunct ] $(TOPDIR)\include\loc/_num_get.cc(196) : see reference to function template instantiation 'const _Facet &std::use_facet>(const std::locale &)' being compiled with [ _Facet=std::numpunct, _CharT=wchar_t ] $(TOPDIR)\include\loc/_num_get.cc(172) : while compiling class template member function 'std::istreambuf_iterator<_CharT,_Traits> std::num_get<_CharT,_InputIter>::do_get(std::istreambuf_iterator<_CharT,_Traits>,std::istreambuf_iterator<_CharT,_Traits>,std::ios_base &,_
[jira] Commented: (STDCXX-562) [Intel C++ 9.1/SuSE Linux/AMD64, shared] SIGSEGV in tests
[ https://issues.apache.org/jira/browse/STDCXX-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528784 ] Farid Zaripov commented on STDCXX-562: -- No such problems on 64 bit icc 9.1 on Windows. > [Intel C++ 9.1/SuSE Linux/AMD64, shared] SIGSEGV in tests > - > > Key: STDCXX-562 > URL: https://issues.apache.org/jira/browse/STDCXX-562 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: trunk > Environment: Intel C++ 9.1/SuSE Linux/AMD64, shared builds only >Reporter: Martin Sebor > Attachments: linux_suse-9.1-amd64-icc-9.1-12D-575978-log.gz.txt > > > Many string and container tests, as well as some iostream are failing when > compiled with Intel C++ 9.1 on SuSE Linux/AMD64. Examples don't seem to be > affected. Could the problem be in the driver, or related to exceptions? Or > TLS? Builds with Intel C++ 10.0 look good. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-562) [Intel C++ 9.1/SuSE Linux/AMD64, shared] SIGSEGV in tests
[ https://issues.apache.org/jira/browse/STDCXX-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528359 ] Farid Zaripov commented on STDCXX-562: -- I have no access to this platform, but trying to check the 64-bit build with intel c++ 9.1 / Windows. > [Intel C++ 9.1/SuSE Linux/AMD64, shared] SIGSEGV in tests > - > > Key: STDCXX-562 > URL: https://issues.apache.org/jira/browse/STDCXX-562 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: trunk > Environment: Intel C++ 9.1/SuSE Linux/AMD64, shared builds only >Reporter: Martin Sebor > Attachments: linux_suse-9.1-amd64-icc-9.1-12D-575978-log.gz.txt > > > Many string and container tests, as well as some iostream are failing when > compiled with Intel C++ 9.1 on SuSE Linux/AMD64. Examples don't seem to be > affected. Could the problem be in the driver, or related to exceptions? Or > TLS? Builds with Intel C++ 10.0 look good. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-554) [MSVC 7.1] Bad code generation of the std::moneypunct ctor (and possibly of the std::messages ctor)
[
https://issues.apache.org/jira/browse/STDCXX-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov closed STDCXX-554.
Regression: (was: [Regression])
> [MSVC 7.1] Bad code generation of the std::moneypunct ctor (and possibly of
> the std::messages ctor)
> ---
>
> Key: STDCXX-554
> URL: https://issues.apache.org/jira/browse/STDCXX-554
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
>Affects Versions: 4.1.3, trunk
> Environment: MSVC 7.1 with Service Pack 1
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80x86
> Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
> Attachments: stdcxx-554.patch
>
>
> The 22.locale.money.put.cpp test fails on MSVC 7.1 (15s build type) with
> buffer overrun error due to bad code generation.
> Here the assembly code for moneypunct ctor:
> -
> _EXPLICIT moneypunct (_RWSTD_SIZE_T __refs = 0)
> : _RW::__rw_facet (__refs), money_base () { }
> 004018C0 pushebp
> 004018C1 mov ebp,esp
> 004018C3 pushecx
> 004018C4 mov dword ptr [ebp-4],ecx
> 004018C7 mov eax,dword ptr [__refs]
> 004018CA pusheax
> 004018CB mov ecx,dword ptr [this]
> 004018CE call__rw::__rw_facet::__rw_facet (412E20h)
> 004018D3 xor ecx,ecx
> 004018D5 mov edx,dword ptr [this]
> 004018D8 add edx,38h // the sizeof
> (moneypunct) == 0x38
> 004018DB mov byte ptr [edx],cl // here the place of the
> buffer overrun
> 004018DD mov eax,dword ptr [this]
> 004018E0 mov dword ptr [eax],offset
> std::moneypunct::`vftable' (488838h)
> 004018E6 mov eax,dword ptr [this]
> 004018E9 mov esp,ebp
> 004018EB pop ebp
> 004018EC ret 4
> -
> When I commented the money_base () call the test succeeded and assembly
> code has changed to:
> -
> _EXPLICIT moneypunct (_RWSTD_SIZE_T __refs = 0)
> : _RW::__rw_facet (__refs)/*, money_base ()*/ { }
> 004018C0 pushebp
> 004018C1 mov ebp,esp
> 004018C3 pushecx
> 004018C4 mov dword ptr [ebp-4],ecx
> 004018C7 mov eax,dword ptr [__refs]
> 004018CA pusheax
> 004018CB mov ecx,dword ptr [this]
> 004018CE call__rw::__rw_facet::__rw_facet (412E20h)
> 004018D3 mov ecx,dword ptr [this]
> 004018D6 mov dword ptr [ecx],offset
> std::moneypunct::`vftable' (488838h)
> 004018DC mov eax,dword ptr [this]
> 004018DF mov esp,ebp
> 004018E1 pop ebp
> 004018E2 ret 4
> -
> Here the same assembly, but in 12s configuration:
> before change:
> -
> const PunctT pun;
> 004018B1 push1
> 004018B3 lea ecx,[esp+0B4h]
> 004018BA call__rw::__rw_facet::__rw_facet (40A770h)
> 004018BF mov byte ptr [esp+0E8h],bl// 0xE8 - 0xB4 ==
> 0x34, so here not buffer overrun,
>
> // but maybe changed last 4-byte member of the __rw_facet
>
> // (I suppose is _C_pid)
> 004018C6 mov dword ptr [esp+0B0h],offset Punct::`vftable'
> (43A258h)
> -
> after change:
> -
> const PunctT pun;
> 00401891 push1
> 00401893 lea ecx,[esp+0B4h]
> 0040189A call__rw::__rw_facet::__rw_facet (40A720h)
> 0040189F mov dword ptr [esp+0B0h],offset Punct::`vftable'
> (43A258h)
> -
> I have not verified, but I suppose that the same problem might be with
> messages class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-554) [MSVC 7.1] Bad code generation of the std::moneypunct ctor (and possibly of the std::messages ctor)
[
https://issues.apache.org/jira/browse/STDCXX-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-554:
-
Regression: [Regression]
The regression test added thus: http://svn.apache.org/viewvc?rev=575614&view=rev
> [MSVC 7.1] Bad code generation of the std::moneypunct ctor (and possibly of
> the std::messages ctor)
> ---
>
> Key: STDCXX-554
> URL: https://issues.apache.org/jira/browse/STDCXX-554
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
>Affects Versions: 4.1.3, trunk
> Environment: MSVC 7.1 with Service Pack 1
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80x86
> Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
> Attachments: stdcxx-554.patch
>
>
> The 22.locale.money.put.cpp test fails on MSVC 7.1 (15s build type) with
> buffer overrun error due to bad code generation.
> Here the assembly code for moneypunct ctor:
> -
> _EXPLICIT moneypunct (_RWSTD_SIZE_T __refs = 0)
> : _RW::__rw_facet (__refs), money_base () { }
> 004018C0 pushebp
> 004018C1 mov ebp,esp
> 004018C3 pushecx
> 004018C4 mov dword ptr [ebp-4],ecx
> 004018C7 mov eax,dword ptr [__refs]
> 004018CA pusheax
> 004018CB mov ecx,dword ptr [this]
> 004018CE call__rw::__rw_facet::__rw_facet (412E20h)
> 004018D3 xor ecx,ecx
> 004018D5 mov edx,dword ptr [this]
> 004018D8 add edx,38h // the sizeof
> (moneypunct) == 0x38
> 004018DB mov byte ptr [edx],cl // here the place of the
> buffer overrun
> 004018DD mov eax,dword ptr [this]
> 004018E0 mov dword ptr [eax],offset
> std::moneypunct::`vftable' (488838h)
> 004018E6 mov eax,dword ptr [this]
> 004018E9 mov esp,ebp
> 004018EB pop ebp
> 004018EC ret 4
> -
> When I commented the money_base () call the test succeeded and assembly
> code has changed to:
> -
> _EXPLICIT moneypunct (_RWSTD_SIZE_T __refs = 0)
> : _RW::__rw_facet (__refs)/*, money_base ()*/ { }
> 004018C0 pushebp
> 004018C1 mov ebp,esp
> 004018C3 pushecx
> 004018C4 mov dword ptr [ebp-4],ecx
> 004018C7 mov eax,dword ptr [__refs]
> 004018CA pusheax
> 004018CB mov ecx,dword ptr [this]
> 004018CE call__rw::__rw_facet::__rw_facet (412E20h)
> 004018D3 mov ecx,dword ptr [this]
> 004018D6 mov dword ptr [ecx],offset
> std::moneypunct::`vftable' (488838h)
> 004018DC mov eax,dword ptr [this]
> 004018DF mov esp,ebp
> 004018E1 pop ebp
> 004018E2 ret 4
> -
> Here the same assembly, but in 12s configuration:
> before change:
> -
> const PunctT pun;
> 004018B1 push1
> 004018B3 lea ecx,[esp+0B4h]
> 004018BA call__rw::__rw_facet::__rw_facet (40A770h)
> 004018BF mov byte ptr [esp+0E8h],bl// 0xE8 - 0xB4 ==
> 0x34, so here not buffer overrun,
>
> // but maybe changed last 4-byte member of the __rw_facet
>
> // (I suppose is _C_pid)
> 004018C6 mov dword ptr [esp+0B0h],offset Punct::`vftable'
> (43A258h)
> -
> after change:
> -
> const PunctT pun;
> 00401891 push1
> 00401893 lea ecx,[esp+0B4h]
> 0040189A call__rw::__rw_facet::__rw_facet (40A720h)
> 0040189F mov dword ptr [esp+0B0h],offset Punct::`vftable'
> (43A258h)
> -
> I have not verified, but I suppose that the same problem might be with
> messages class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-554) [MSVC 7.1] Bad code generation of the std::moneypunct ctor (and possibly of the std::messages ctor)
[
https://issues.apache.org/jira/browse/STDCXX-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov resolved STDCXX-554.
--
Resolution: Fixed
Fixed thus: http://svn.apache.org/viewvc?rev=575613&view=rev
> [MSVC 7.1] Bad code generation of the std::moneypunct ctor (and possibly of
> the std::messages ctor)
> ---
>
> Key: STDCXX-554
> URL: https://issues.apache.org/jira/browse/STDCXX-554
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
>Affects Versions: 4.1.3, trunk
> Environment: MSVC 7.1 with Service Pack 1
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80x86
> Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
> Attachments: stdcxx-554.patch
>
>
> The 22.locale.money.put.cpp test fails on MSVC 7.1 (15s build type) with
> buffer overrun error due to bad code generation.
> Here the assembly code for moneypunct ctor:
> -
> _EXPLICIT moneypunct (_RWSTD_SIZE_T __refs = 0)
> : _RW::__rw_facet (__refs), money_base () { }
> 004018C0 pushebp
> 004018C1 mov ebp,esp
> 004018C3 pushecx
> 004018C4 mov dword ptr [ebp-4],ecx
> 004018C7 mov eax,dword ptr [__refs]
> 004018CA pusheax
> 004018CB mov ecx,dword ptr [this]
> 004018CE call__rw::__rw_facet::__rw_facet (412E20h)
> 004018D3 xor ecx,ecx
> 004018D5 mov edx,dword ptr [this]
> 004018D8 add edx,38h // the sizeof
> (moneypunct) == 0x38
> 004018DB mov byte ptr [edx],cl // here the place of the
> buffer overrun
> 004018DD mov eax,dword ptr [this]
> 004018E0 mov dword ptr [eax],offset
> std::moneypunct::`vftable' (488838h)
> 004018E6 mov eax,dword ptr [this]
> 004018E9 mov esp,ebp
> 004018EB pop ebp
> 004018EC ret 4
> -
> When I commented the money_base () call the test succeeded and assembly
> code has changed to:
> -
> _EXPLICIT moneypunct (_RWSTD_SIZE_T __refs = 0)
> : _RW::__rw_facet (__refs)/*, money_base ()*/ { }
> 004018C0 pushebp
> 004018C1 mov ebp,esp
> 004018C3 pushecx
> 004018C4 mov dword ptr [ebp-4],ecx
> 004018C7 mov eax,dword ptr [__refs]
> 004018CA pusheax
> 004018CB mov ecx,dword ptr [this]
> 004018CE call__rw::__rw_facet::__rw_facet (412E20h)
> 004018D3 mov ecx,dword ptr [this]
> 004018D6 mov dword ptr [ecx],offset
> std::moneypunct::`vftable' (488838h)
> 004018DC mov eax,dword ptr [this]
> 004018DF mov esp,ebp
> 004018E1 pop ebp
> 004018E2 ret 4
> -
> Here the same assembly, but in 12s configuration:
> before change:
> -
> const PunctT pun;
> 004018B1 push1
> 004018B3 lea ecx,[esp+0B4h]
> 004018BA call__rw::__rw_facet::__rw_facet (40A770h)
> 004018BF mov byte ptr [esp+0E8h],bl// 0xE8 - 0xB4 ==
> 0x34, so here not buffer overrun,
>
> // but maybe changed last 4-byte member of the __rw_facet
>
> // (I suppose is _C_pid)
> 004018C6 mov dword ptr [esp+0B0h],offset Punct::`vftable'
> (43A258h)
> -
> after change:
> -
> const PunctT pun;
> 00401891 push1
> 00401893 lea ecx,[esp+0B4h]
> 0040189A call__rw::__rw_facet::__rw_facet (40A720h)
> 0040189F mov dword ptr [esp+0B0h],offset Punct::`vftable'
> (43A258h)
> -
> I have not verified, but I suppose that the same problem might be with
> messages class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-554) [MSVC 7.1] Bad code generation of the std::moneypunct ctor (and possibly of the std::messages ctor)
[
https://issues.apache.org/jira/browse/STDCXX-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-554:
-
Fix Version/s: 4.2
> [MSVC 7.1] Bad code generation of the std::moneypunct ctor (and possibly of
> the std::messages ctor)
> ---
>
> Key: STDCXX-554
> URL: https://issues.apache.org/jira/browse/STDCXX-554
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
>Affects Versions: 4.1.3, trunk
> Environment: MSVC 7.1 with Service Pack 1
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80x86
> Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
> Attachments: stdcxx-554.patch
>
>
> The 22.locale.money.put.cpp test fails on MSVC 7.1 (15s build type) with
> buffer overrun error due to bad code generation.
> Here the assembly code for moneypunct ctor:
> -
> _EXPLICIT moneypunct (_RWSTD_SIZE_T __refs = 0)
> : _RW::__rw_facet (__refs), money_base () { }
> 004018C0 pushebp
> 004018C1 mov ebp,esp
> 004018C3 pushecx
> 004018C4 mov dword ptr [ebp-4],ecx
> 004018C7 mov eax,dword ptr [__refs]
> 004018CA pusheax
> 004018CB mov ecx,dword ptr [this]
> 004018CE call__rw::__rw_facet::__rw_facet (412E20h)
> 004018D3 xor ecx,ecx
> 004018D5 mov edx,dword ptr [this]
> 004018D8 add edx,38h // the sizeof
> (moneypunct) == 0x38
> 004018DB mov byte ptr [edx],cl // here the place of the
> buffer overrun
> 004018DD mov eax,dword ptr [this]
> 004018E0 mov dword ptr [eax],offset
> std::moneypunct::`vftable' (488838h)
> 004018E6 mov eax,dword ptr [this]
> 004018E9 mov esp,ebp
> 004018EB pop ebp
> 004018EC ret 4
> -
> When I commented the money_base () call the test succeeded and assembly
> code has changed to:
> -
> _EXPLICIT moneypunct (_RWSTD_SIZE_T __refs = 0)
> : _RW::__rw_facet (__refs)/*, money_base ()*/ { }
> 004018C0 pushebp
> 004018C1 mov ebp,esp
> 004018C3 pushecx
> 004018C4 mov dword ptr [ebp-4],ecx
> 004018C7 mov eax,dword ptr [__refs]
> 004018CA pusheax
> 004018CB mov ecx,dword ptr [this]
> 004018CE call__rw::__rw_facet::__rw_facet (412E20h)
> 004018D3 mov ecx,dword ptr [this]
> 004018D6 mov dword ptr [ecx],offset
> std::moneypunct::`vftable' (488838h)
> 004018DC mov eax,dword ptr [this]
> 004018DF mov esp,ebp
> 004018E1 pop ebp
> 004018E2 ret 4
> -
> Here the same assembly, but in 12s configuration:
> before change:
> -
> const PunctT pun;
> 004018B1 push1
> 004018B3 lea ecx,[esp+0B4h]
> 004018BA call__rw::__rw_facet::__rw_facet (40A770h)
> 004018BF mov byte ptr [esp+0E8h],bl// 0xE8 - 0xB4 ==
> 0x34, so here not buffer overrun,
>
> // but maybe changed last 4-byte member of the __rw_facet
>
> // (I suppose is _C_pid)
> 004018C6 mov dword ptr [esp+0B0h],offset Punct::`vftable'
> (43A258h)
> -
> after change:
> -
> const PunctT pun;
> 00401891 push1
> 00401893 lea ecx,[esp+0B4h]
> 0040189A call__rw::__rw_facet::__rw_facet (40A720h)
> 0040189F mov dword ptr [esp+0B0h],offset Punct::`vftable'
> (43A258h)
> -
> I have not verified, but I suppose that the same problem might be with
> messages class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-554) [MSVC 7.1] Bad code generation of the std::moneypunct ctor (and possibly of the std::messages ctor)
[
https://issues.apache.org/jira/browse/STDCXX-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov reassigned STDCXX-554:
Assignee: Farid Zaripov
> [MSVC 7.1] Bad code generation of the std::moneypunct ctor (and possibly of
> the std::messages ctor)
> ---
>
> Key: STDCXX-554
> URL: https://issues.apache.org/jira/browse/STDCXX-554
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
>Affects Versions: 4.1.3, trunk
> Environment: MSVC 7.1 with Service Pack 1
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80x86
> Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Attachments: stdcxx-554.patch
>
>
> The 22.locale.money.put.cpp test fails on MSVC 7.1 (15s build type) with
> buffer overrun error due to bad code generation.
> Here the assembly code for moneypunct ctor:
> -
> _EXPLICIT moneypunct (_RWSTD_SIZE_T __refs = 0)
> : _RW::__rw_facet (__refs), money_base () { }
> 004018C0 pushebp
> 004018C1 mov ebp,esp
> 004018C3 pushecx
> 004018C4 mov dword ptr [ebp-4],ecx
> 004018C7 mov eax,dword ptr [__refs]
> 004018CA pusheax
> 004018CB mov ecx,dword ptr [this]
> 004018CE call__rw::__rw_facet::__rw_facet (412E20h)
> 004018D3 xor ecx,ecx
> 004018D5 mov edx,dword ptr [this]
> 004018D8 add edx,38h // the sizeof
> (moneypunct) == 0x38
> 004018DB mov byte ptr [edx],cl // here the place of the
> buffer overrun
> 004018DD mov eax,dword ptr [this]
> 004018E0 mov dword ptr [eax],offset
> std::moneypunct::`vftable' (488838h)
> 004018E6 mov eax,dword ptr [this]
> 004018E9 mov esp,ebp
> 004018EB pop ebp
> 004018EC ret 4
> -
> When I commented the money_base () call the test succeeded and assembly
> code has changed to:
> -
> _EXPLICIT moneypunct (_RWSTD_SIZE_T __refs = 0)
> : _RW::__rw_facet (__refs)/*, money_base ()*/ { }
> 004018C0 pushebp
> 004018C1 mov ebp,esp
> 004018C3 pushecx
> 004018C4 mov dword ptr [ebp-4],ecx
> 004018C7 mov eax,dword ptr [__refs]
> 004018CA pusheax
> 004018CB mov ecx,dword ptr [this]
> 004018CE call__rw::__rw_facet::__rw_facet (412E20h)
> 004018D3 mov ecx,dword ptr [this]
> 004018D6 mov dword ptr [ecx],offset
> std::moneypunct::`vftable' (488838h)
> 004018DC mov eax,dword ptr [this]
> 004018DF mov esp,ebp
> 004018E1 pop ebp
> 004018E2 ret 4
> -
> Here the same assembly, but in 12s configuration:
> before change:
> -
> const PunctT pun;
> 004018B1 push1
> 004018B3 lea ecx,[esp+0B4h]
> 004018BA call__rw::__rw_facet::__rw_facet (40A770h)
> 004018BF mov byte ptr [esp+0E8h],bl// 0xE8 - 0xB4 ==
> 0x34, so here not buffer overrun,
>
> // but maybe changed last 4-byte member of the __rw_facet
>
> // (I suppose is _C_pid)
> 004018C6 mov dword ptr [esp+0B0h],offset Punct::`vftable'
> (43A258h)
> -
> after change:
> -
> const PunctT pun;
> 00401891 push1
> 00401893 lea ecx,[esp+0B4h]
> 0040189A call__rw::__rw_facet::__rw_facet (40A720h)
> 0040189F mov dword ptr [esp+0B0h],offset Punct::`vftable'
> (43A258h)
> -
> I have not verified, but I suppose that the same problem might be with
> messages class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-554) [MSVC 7.1] Bad code generation of the std::moneypunct ctor (and possibly of the std::messages ctor)
[
https://issues.apache.org/jira/browse/STDCXX-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-554:
-
Summary: [MSVC 7.1] Bad code generation of the std::moneypunct ctor (and
possibly of the std::messages ctor) (was: Bad code generation of the
std::moneypunct ctor (and possibly of the std::messages ctor))
> [MSVC 7.1] Bad code generation of the std::moneypunct ctor (and possibly of
> the std::messages ctor)
> ---
>
> Key: STDCXX-554
> URL: https://issues.apache.org/jira/browse/STDCXX-554
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
>Affects Versions: 4.1.3, trunk
> Environment: MSVC 7.1 with Service Pack 1
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80x86
> Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
>Reporter: Farid Zaripov
> Attachments: stdcxx-554.patch
>
>
> The 22.locale.money.put.cpp test fails on MSVC 7.1 (15s build type) with
> buffer overrun error due to bad code generation.
> Here the assembly code for moneypunct ctor:
> -
> _EXPLICIT moneypunct (_RWSTD_SIZE_T __refs = 0)
> : _RW::__rw_facet (__refs), money_base () { }
> 004018C0 pushebp
> 004018C1 mov ebp,esp
> 004018C3 pushecx
> 004018C4 mov dword ptr [ebp-4],ecx
> 004018C7 mov eax,dword ptr [__refs]
> 004018CA pusheax
> 004018CB mov ecx,dword ptr [this]
> 004018CE call__rw::__rw_facet::__rw_facet (412E20h)
> 004018D3 xor ecx,ecx
> 004018D5 mov edx,dword ptr [this]
> 004018D8 add edx,38h // the sizeof
> (moneypunct) == 0x38
> 004018DB mov byte ptr [edx],cl // here the place of the
> buffer overrun
> 004018DD mov eax,dword ptr [this]
> 004018E0 mov dword ptr [eax],offset
> std::moneypunct::`vftable' (488838h)
> 004018E6 mov eax,dword ptr [this]
> 004018E9 mov esp,ebp
> 004018EB pop ebp
> 004018EC ret 4
> -
> When I commented the money_base () call the test succeeded and assembly
> code has changed to:
> -
> _EXPLICIT moneypunct (_RWSTD_SIZE_T __refs = 0)
> : _RW::__rw_facet (__refs)/*, money_base ()*/ { }
> 004018C0 pushebp
> 004018C1 mov ebp,esp
> 004018C3 pushecx
> 004018C4 mov dword ptr [ebp-4],ecx
> 004018C7 mov eax,dword ptr [__refs]
> 004018CA pusheax
> 004018CB mov ecx,dword ptr [this]
> 004018CE call__rw::__rw_facet::__rw_facet (412E20h)
> 004018D3 mov ecx,dword ptr [this]
> 004018D6 mov dword ptr [ecx],offset
> std::moneypunct::`vftable' (488838h)
> 004018DC mov eax,dword ptr [this]
> 004018DF mov esp,ebp
> 004018E1 pop ebp
> 004018E2 ret 4
> -
> Here the same assembly, but in 12s configuration:
> before change:
> -
> const PunctT pun;
> 004018B1 push1
> 004018B3 lea ecx,[esp+0B4h]
> 004018BA call__rw::__rw_facet::__rw_facet (40A770h)
> 004018BF mov byte ptr [esp+0E8h],bl// 0xE8 - 0xB4 ==
> 0x34, so here not buffer overrun,
>
> // but maybe changed last 4-byte member of the __rw_facet
>
> // (I suppose is _C_pid)
> 004018C6 mov dword ptr [esp+0B0h],offset Punct::`vftable'
> (43A258h)
> -
> after change:
> -
> const PunctT pun;
> 00401891 push1
> 00401893 lea ecx,[esp+0B4h]
> 0040189A call__rw::__rw_facet::__rw_facet (40A720h)
> 0040189F mov dword ptr [esp+0B0h],offset Punct::`vftable'
> (43A258h)
> -
> I have not verified, but I suppose that the same problem might be with
> messages class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-556) [MSVC 7.1] Bug in implementation of the empty base optimization
[
https://issues.apache.org/jira/browse/STDCXX-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-556:
-
Environment:
MSVC 7.1 with Service Pack 1
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
was:MSVC 7.1
Summary: [MSVC 7.1] Bug in implementation of the empty base
optimization (was: Bug in MSVC 7.1 implementation of the empty base
optimization)
> [MSVC 7.1] Bug in implementation of the empty base optimization
> ---
>
> Key: STDCXX-556
> URL: https://issues.apache.org/jira/browse/STDCXX-556
> Project: C++ Standard Library
> Issue Type: Bug
> Components: External
> Environment: MSVC 7.1 with Service Pack 1
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80x86
> Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
>Reporter: Farid Zaripov
>
> The test below exit with exitcode 1 due to bug in MSVC 7.1 implementation of
> the empty base optimization.
> -
> #include
> #include
> #include
> class empty_base { };
> class base
> {
> public:
> base (int val) : __val (val) { }
> volatile int __val;
> };
> class derived1 : public base, public empty_base
> {
> public:
> derived1 (int val) : base (val), empty_base () { }
> };
> class derived2 : public base, public empty_base
> {
> public:
> derived2 (int val) : base (val) { }
> };
> template
> int foo (const int val, const char* name)
> {
> const char fill = '\xdc';
> char buf [sizeof (T) + 1];
> std::memset (buf, fill, sizeof (buf));
> T* t = new (buf) T (val);
> int ret = 0;
> if (fill != buf [sizeof (T)]) {
> ++ret;
> std::printf ("buf [sizeof (%s)] expected %d, got %d\n",
> name, int (fill), int (buf [sizeof (T)]));
> }
> if (val != t->__val) {
> ++ret;
> std::printf ("%s::__val expected %d, got %d\n",
> name, val, t->__val);
> }
> t->~T ();
> return ret;
> }
> int main(int, char**)
> {
> const int init = 0xcdcdcdcd;
> return foo (init, "derived1")
>+ foo (init, "derived2");
> }
> -
> The test output:
> -
> buf [sizeof (derived1)] expected -36, got 0
> -
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-556) Bug in MSVC 7.1 implementation of the empty base optimization
Bug in MSVC 7.1 implementation of the empty base optimization
-
Key: STDCXX-556
URL: https://issues.apache.org/jira/browse/STDCXX-556
Project: C++ Standard Library
Issue Type: Bug
Components: External
Environment: MSVC 7.1
Reporter: Farid Zaripov
The test below exit with exitcode 1 due to bug in MSVC 7.1 implementation of
the empty base optimization.
-
#include
#include
#include
class empty_base { };
class base
{
public:
base (int val) : __val (val) { }
volatile int __val;
};
class derived1 : public base, public empty_base
{
public:
derived1 (int val) : base (val), empty_base () { }
};
class derived2 : public base, public empty_base
{
public:
derived2 (int val) : base (val) { }
};
template
int foo (const int val, const char* name)
{
const char fill = '\xdc';
char buf [sizeof (T) + 1];
std::memset (buf, fill, sizeof (buf));
T* t = new (buf) T (val);
int ret = 0;
if (fill != buf [sizeof (T)]) {
++ret;
std::printf ("buf [sizeof (%s)] expected %d, got %d\n",
name, int (fill), int (buf [sizeof (T)]));
}
if (val != t->__val) {
++ret;
std::printf ("%s::__val expected %d, got %d\n",
name, val, t->__val);
}
t->~T ();
return ret;
}
int main(int, char**)
{
const int init = 0xcdcdcdcd;
return foo (init, "derived1")
+ foo (init, "derived2");
}
-
The test output:
-
buf [sizeof (derived1)] expected -36, got 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-554) Bad code generation of the std::moneypunct ctor (and possibly of the std::messages ctor)
[
https://issues.apache.org/jira/browse/STDCXX-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-554:
-
Environment:
MSVC 7.1 with Service Pack 1
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
was:MSVC 7.1
> Bad code generation of the std::moneypunct ctor (and possibly of the
> std::messages ctor)
>
>
> Key: STDCXX-554
> URL: https://issues.apache.org/jira/browse/STDCXX-554
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
>Affects Versions: 4.1.3, trunk
> Environment: MSVC 7.1 with Service Pack 1
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80x86
> Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
>Reporter: Farid Zaripov
> Attachments: stdcxx-554.patch
>
>
> The 22.locale.money.put.cpp test fails on MSVC 7.1 (15s build type) with
> buffer overrun error due to bad code generation.
> Here the assembly code for moneypunct ctor:
> -
> _EXPLICIT moneypunct (_RWSTD_SIZE_T __refs = 0)
> : _RW::__rw_facet (__refs), money_base () { }
> 004018C0 pushebp
> 004018C1 mov ebp,esp
> 004018C3 pushecx
> 004018C4 mov dword ptr [ebp-4],ecx
> 004018C7 mov eax,dword ptr [__refs]
> 004018CA pusheax
> 004018CB mov ecx,dword ptr [this]
> 004018CE call__rw::__rw_facet::__rw_facet (412E20h)
> 004018D3 xor ecx,ecx
> 004018D5 mov edx,dword ptr [this]
> 004018D8 add edx,38h // the sizeof
> (moneypunct) == 0x38
> 004018DB mov byte ptr [edx],cl // here the place of the
> buffer overrun
> 004018DD mov eax,dword ptr [this]
> 004018E0 mov dword ptr [eax],offset
> std::moneypunct::`vftable' (488838h)
> 004018E6 mov eax,dword ptr [this]
> 004018E9 mov esp,ebp
> 004018EB pop ebp
> 004018EC ret 4
> -
> When I commented the money_base () call the test succeeded and assembly
> code has changed to:
> -
> _EXPLICIT moneypunct (_RWSTD_SIZE_T __refs = 0)
> : _RW::__rw_facet (__refs)/*, money_base ()*/ { }
> 004018C0 pushebp
> 004018C1 mov ebp,esp
> 004018C3 pushecx
> 004018C4 mov dword ptr [ebp-4],ecx
> 004018C7 mov eax,dword ptr [__refs]
> 004018CA pusheax
> 004018CB mov ecx,dword ptr [this]
> 004018CE call__rw::__rw_facet::__rw_facet (412E20h)
> 004018D3 mov ecx,dword ptr [this]
> 004018D6 mov dword ptr [ecx],offset
> std::moneypunct::`vftable' (488838h)
> 004018DC mov eax,dword ptr [this]
> 004018DF mov esp,ebp
> 004018E1 pop ebp
> 004018E2 ret 4
> -
> Here the same assembly, but in 12s configuration:
> before change:
> -
> const PunctT pun;
> 004018B1 push1
> 004018B3 lea ecx,[esp+0B4h]
> 004018BA call__rw::__rw_facet::__rw_facet (40A770h)
> 004018BF mov byte ptr [esp+0E8h],bl// 0xE8 - 0xB4 ==
> 0x34, so here not buffer overrun,
>
> // but maybe changed last 4-byte member of the __rw_facet
>
> // (I suppose is _C_pid)
> 004018C6 mov dword ptr [esp+0B0h],offset Punct::`vftable'
> (43A258h)
> -
> after change:
> -
> const PunctT pun;
> 00401891 push1
> 00401893 lea ecx,[esp+0B4h]
> 0040189A call__rw::__rw_facet::__rw_facet (40A720h)
> 0040189F mov dword ptr [esp+0B0h],offset Punct::`vftable'
> (43A258h)
> -
> I have not verified, but I suppose that the same problem might be with
> messages class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-554) Bad code generation of the std::moneypunct ctor (and possibly of the std::messages ctor)
[
https://issues.apache.org/jira/browse/STDCXX-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-554:
-
Affects Version/s: 4.1.3
> Bad code generation of the std::moneypunct ctor (and possibly of the
> std::messages ctor)
>
>
> Key: STDCXX-554
> URL: https://issues.apache.org/jira/browse/STDCXX-554
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
>Affects Versions: 4.1.3, trunk
> Environment: MSVC 7.1
>Reporter: Farid Zaripov
> Attachments: stdcxx-554.patch
>
>
> The 22.locale.money.put.cpp test fails on MSVC 7.1 (15s build type) with
> buffer overrun error due to bad code generation.
> Here the assembly code for moneypunct ctor:
> -
> _EXPLICIT moneypunct (_RWSTD_SIZE_T __refs = 0)
> : _RW::__rw_facet (__refs), money_base () { }
> 004018C0 pushebp
> 004018C1 mov ebp,esp
> 004018C3 pushecx
> 004018C4 mov dword ptr [ebp-4],ecx
> 004018C7 mov eax,dword ptr [__refs]
> 004018CA pusheax
> 004018CB mov ecx,dword ptr [this]
> 004018CE call__rw::__rw_facet::__rw_facet (412E20h)
> 004018D3 xor ecx,ecx
> 004018D5 mov edx,dword ptr [this]
> 004018D8 add edx,38h // the sizeof
> (moneypunct) == 0x38
> 004018DB mov byte ptr [edx],cl // here the place of the
> buffer overrun
> 004018DD mov eax,dword ptr [this]
> 004018E0 mov dword ptr [eax],offset
> std::moneypunct::`vftable' (488838h)
> 004018E6 mov eax,dword ptr [this]
> 004018E9 mov esp,ebp
> 004018EB pop ebp
> 004018EC ret 4
> -
> When I commented the money_base () call the test succeeded and assembly
> code has changed to:
> -
> _EXPLICIT moneypunct (_RWSTD_SIZE_T __refs = 0)
> : _RW::__rw_facet (__refs)/*, money_base ()*/ { }
> 004018C0 pushebp
> 004018C1 mov ebp,esp
> 004018C3 pushecx
> 004018C4 mov dword ptr [ebp-4],ecx
> 004018C7 mov eax,dword ptr [__refs]
> 004018CA pusheax
> 004018CB mov ecx,dword ptr [this]
> 004018CE call__rw::__rw_facet::__rw_facet (412E20h)
> 004018D3 mov ecx,dword ptr [this]
> 004018D6 mov dword ptr [ecx],offset
> std::moneypunct::`vftable' (488838h)
> 004018DC mov eax,dword ptr [this]
> 004018DF mov esp,ebp
> 004018E1 pop ebp
> 004018E2 ret 4
> -
> Here the same assembly, but in 12s configuration:
> before change:
> -
> const PunctT pun;
> 004018B1 push1
> 004018B3 lea ecx,[esp+0B4h]
> 004018BA call__rw::__rw_facet::__rw_facet (40A770h)
> 004018BF mov byte ptr [esp+0E8h],bl// 0xE8 - 0xB4 ==
> 0x34, so here not buffer overrun,
>
> // but maybe changed last 4-byte member of the __rw_facet
>
> // (I suppose is _C_pid)
> 004018C6 mov dword ptr [esp+0B0h],offset Punct::`vftable'
> (43A258h)
> -
> after change:
> -
> const PunctT pun;
> 00401891 push1
> 00401893 lea ecx,[esp+0B4h]
> 0040189A call__rw::__rw_facet::__rw_facet (40A720h)
> 0040189F mov dword ptr [esp+0B0h],offset Punct::`vftable'
> (43A258h)
> -
> I have not verified, but I suppose that the same problem might be with
> messages class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-554) Bad code generation of the std::moneypunct ctor (and possibly of the std::messages ctor)
[
https://issues.apache.org/jira/browse/STDCXX-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527206
]
Farid Zaripov commented on STDCXX-554:
--
The reference thread in development mailing-list:
http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg04931.html
> Bad code generation of the std::moneypunct ctor (and possibly of the
> std::messages ctor)
>
>
> Key: STDCXX-554
> URL: https://issues.apache.org/jira/browse/STDCXX-554
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
>Affects Versions: trunk
> Environment: MSVC 7.1
>Reporter: Farid Zaripov
> Attachments: stdcxx-554.patch
>
>
> The 22.locale.money.put.cpp test fails on MSVC 7.1 (15s build type) with
> buffer overrun error due to bad code generation.
> Here the assembly code for moneypunct ctor:
> -
> _EXPLICIT moneypunct (_RWSTD_SIZE_T __refs = 0)
> : _RW::__rw_facet (__refs), money_base () { }
> 004018C0 pushebp
> 004018C1 mov ebp,esp
> 004018C3 pushecx
> 004018C4 mov dword ptr [ebp-4],ecx
> 004018C7 mov eax,dword ptr [__refs]
> 004018CA pusheax
> 004018CB mov ecx,dword ptr [this]
> 004018CE call__rw::__rw_facet::__rw_facet (412E20h)
> 004018D3 xor ecx,ecx
> 004018D5 mov edx,dword ptr [this]
> 004018D8 add edx,38h // the sizeof
> (moneypunct) == 0x38
> 004018DB mov byte ptr [edx],cl // here the place of the
> buffer overrun
> 004018DD mov eax,dword ptr [this]
> 004018E0 mov dword ptr [eax],offset
> std::moneypunct::`vftable' (488838h)
> 004018E6 mov eax,dword ptr [this]
> 004018E9 mov esp,ebp
> 004018EB pop ebp
> 004018EC ret 4
> -
> When I commented the money_base () call the test succeeded and assembly
> code has changed to:
> -
> _EXPLICIT moneypunct (_RWSTD_SIZE_T __refs = 0)
> : _RW::__rw_facet (__refs)/*, money_base ()*/ { }
> 004018C0 pushebp
> 004018C1 mov ebp,esp
> 004018C3 pushecx
> 004018C4 mov dword ptr [ebp-4],ecx
> 004018C7 mov eax,dword ptr [__refs]
> 004018CA pusheax
> 004018CB mov ecx,dword ptr [this]
> 004018CE call__rw::__rw_facet::__rw_facet (412E20h)
> 004018D3 mov ecx,dword ptr [this]
> 004018D6 mov dword ptr [ecx],offset
> std::moneypunct::`vftable' (488838h)
> 004018DC mov eax,dword ptr [this]
> 004018DF mov esp,ebp
> 004018E1 pop ebp
> 004018E2 ret 4
> -
> Here the same assembly, but in 12s configuration:
> before change:
> -
> const PunctT pun;
> 004018B1 push1
> 004018B3 lea ecx,[esp+0B4h]
> 004018BA call__rw::__rw_facet::__rw_facet (40A770h)
> 004018BF mov byte ptr [esp+0E8h],bl// 0xE8 - 0xB4 ==
> 0x34, so here not buffer overrun,
>
> // but maybe changed last 4-byte member of the __rw_facet
>
> // (I suppose is _C_pid)
> 004018C6 mov dword ptr [esp+0B0h],offset Punct::`vftable'
> (43A258h)
> -
> after change:
> -
> const PunctT pun;
> 00401891 push1
> 00401893 lea ecx,[esp+0B4h]
> 0040189A call__rw::__rw_facet::__rw_facet (40A720h)
> 0040189F mov dword ptr [esp+0B0h],offset Punct::`vftable'
> (43A258h)
> -
> I have not verified, but I suppose that the same problem might be with
> messages class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-554) Bad code generation of the std::moneypunct ctor (and possibly of the std::messages ctor)
Bad code generation of the std::moneypunct ctor (and possibly of the
std::messages ctor)
Key: STDCXX-554
URL: https://issues.apache.org/jira/browse/STDCXX-554
Project: C++ Standard Library
Issue Type: Bug
Components: 22. Localization
Affects Versions: trunk
Environment: MSVC 7.1
Reporter: Farid Zaripov
Attachments: stdcxx-554.patch
The 22.locale.money.put.cpp test fails on MSVC 7.1 (15s build type) with
buffer overrun error due to bad code generation.
Here the assembly code for moneypunct ctor:
-
_EXPLICIT moneypunct (_RWSTD_SIZE_T __refs = 0)
: _RW::__rw_facet (__refs), money_base () { }
004018C0 pushebp
004018C1 mov ebp,esp
004018C3 pushecx
004018C4 mov dword ptr [ebp-4],ecx
004018C7 mov eax,dword ptr [__refs]
004018CA pusheax
004018CB mov ecx,dword ptr [this]
004018CE call__rw::__rw_facet::__rw_facet (412E20h)
004018D3 xor ecx,ecx
004018D5 mov edx,dword ptr [this]
004018D8 add edx,38h // the sizeof (moneypunct)
== 0x38
004018DB mov byte ptr [edx],cl // here the place of the
buffer overrun
004018DD mov eax,dword ptr [this]
004018E0 mov dword ptr [eax],offset std::moneypunct::`vftable'
(488838h)
004018E6 mov eax,dword ptr [this]
004018E9 mov esp,ebp
004018EB pop ebp
004018EC ret 4
-
When I commented the money_base () call the test succeeded and assembly code
has changed to:
-
_EXPLICIT moneypunct (_RWSTD_SIZE_T __refs = 0)
: _RW::__rw_facet (__refs)/*, money_base ()*/ { }
004018C0 pushebp
004018C1 mov ebp,esp
004018C3 pushecx
004018C4 mov dword ptr [ebp-4],ecx
004018C7 mov eax,dword ptr [__refs]
004018CA pusheax
004018CB mov ecx,dword ptr [this]
004018CE call__rw::__rw_facet::__rw_facet (412E20h)
004018D3 mov ecx,dword ptr [this]
004018D6 mov dword ptr [ecx],offset std::moneypunct::`vftable'
(488838h)
004018DC mov eax,dword ptr [this]
004018DF mov esp,ebp
004018E1 pop ebp
004018E2 ret 4
-
Here the same assembly, but in 12s configuration:
before change:
-
const PunctT pun;
004018B1 push1
004018B3 lea ecx,[esp+0B4h]
004018BA call__rw::__rw_facet::__rw_facet (40A770h)
004018BF mov byte ptr [esp+0E8h],bl// 0xE8 - 0xB4 == 0x34,
so here not buffer overrun,
//
but maybe changed last 4-byte member of the __rw_facet
//
(I suppose is _C_pid)
004018C6 mov dword ptr [esp+0B0h],offset Punct::`vftable'
(43A258h)
-
after change:
-
const PunctT pun;
00401891 push1
00401893 lea ecx,[esp+0B4h]
0040189A call__rw::__rw_facet::__rw_facet (40A720h)
0040189F mov dword ptr [esp+0B0h],offset Punct::`vftable'
(43A258h)
-
I have not verified, but I suppose that the same problem might be with
messages class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-554) Bad code generation of the std::moneypunct ctor (and possibly of the std::messages ctor)
[
https://issues.apache.org/jira/browse/STDCXX-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-554:
-
Attachment: stdcxx-554.patch
> Bad code generation of the std::moneypunct ctor (and possibly of the
> std::messages ctor)
>
>
> Key: STDCXX-554
> URL: https://issues.apache.org/jira/browse/STDCXX-554
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
>Affects Versions: trunk
> Environment: MSVC 7.1
>Reporter: Farid Zaripov
> Attachments: stdcxx-554.patch
>
>
> The 22.locale.money.put.cpp test fails on MSVC 7.1 (15s build type) with
> buffer overrun error due to bad code generation.
> Here the assembly code for moneypunct ctor:
> -
> _EXPLICIT moneypunct (_RWSTD_SIZE_T __refs = 0)
> : _RW::__rw_facet (__refs), money_base () { }
> 004018C0 pushebp
> 004018C1 mov ebp,esp
> 004018C3 pushecx
> 004018C4 mov dword ptr [ebp-4],ecx
> 004018C7 mov eax,dword ptr [__refs]
> 004018CA pusheax
> 004018CB mov ecx,dword ptr [this]
> 004018CE call__rw::__rw_facet::__rw_facet (412E20h)
> 004018D3 xor ecx,ecx
> 004018D5 mov edx,dword ptr [this]
> 004018D8 add edx,38h // the sizeof
> (moneypunct) == 0x38
> 004018DB mov byte ptr [edx],cl // here the place of the
> buffer overrun
> 004018DD mov eax,dword ptr [this]
> 004018E0 mov dword ptr [eax],offset
> std::moneypunct::`vftable' (488838h)
> 004018E6 mov eax,dword ptr [this]
> 004018E9 mov esp,ebp
> 004018EB pop ebp
> 004018EC ret 4
> -
> When I commented the money_base () call the test succeeded and assembly
> code has changed to:
> -
> _EXPLICIT moneypunct (_RWSTD_SIZE_T __refs = 0)
> : _RW::__rw_facet (__refs)/*, money_base ()*/ { }
> 004018C0 pushebp
> 004018C1 mov ebp,esp
> 004018C3 pushecx
> 004018C4 mov dword ptr [ebp-4],ecx
> 004018C7 mov eax,dword ptr [__refs]
> 004018CA pusheax
> 004018CB mov ecx,dword ptr [this]
> 004018CE call__rw::__rw_facet::__rw_facet (412E20h)
> 004018D3 mov ecx,dword ptr [this]
> 004018D6 mov dword ptr [ecx],offset
> std::moneypunct::`vftable' (488838h)
> 004018DC mov eax,dword ptr [this]
> 004018DF mov esp,ebp
> 004018E1 pop ebp
> 004018E2 ret 4
> -
> Here the same assembly, but in 12s configuration:
> before change:
> -
> const PunctT pun;
> 004018B1 push1
> 004018B3 lea ecx,[esp+0B4h]
> 004018BA call__rw::__rw_facet::__rw_facet (40A770h)
> 004018BF mov byte ptr [esp+0E8h],bl// 0xE8 - 0xB4 ==
> 0x34, so here not buffer overrun,
>
> // but maybe changed last 4-byte member of the __rw_facet
>
> // (I suppose is _C_pid)
> 004018C6 mov dword ptr [esp+0B0h],offset Punct::`vftable'
> (43A258h)
> -
> after change:
> -
> const PunctT pun;
> 00401891 push1
> 00401893 lea ecx,[esp+0B4h]
> 0040189A call__rw::__rw_facet::__rw_facet (40A720h)
> 0040189F mov dword ptr [esp+0B0h],offset Punct::`vftable'
> (43A258h)
> -
> I have not verified, but I suppose that the same problem might be with
> messages class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (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 resolved STDCXX-543. -- Resolution: Fixed Fix Version/s: 4.2 Fixed thus: http://svn.apache.org/viewvc?rev=575378&view=rev > 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 > > > 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] Assigned: (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 reassigned STDCXX-543: Assignee: Farid Zaripov (was: Andrew Black) > 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 > > 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] Commented: (STDCXX-547) [Sun C++] 64-bit conversion warnings building the library
[ https://issues.apache.org/jira/browse/STDCXX-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526531 ] Farid Zaripov commented on STDCXX-547: -- Below is a warnings when building the library with ICC 10.0 / x64 platform: num_put.cpp $(TOPDIR)\src\num_put.cpp(714): warning #810: conversion from "const void *" to "long" may lose significant bits len = __rw_itoa (buf, _RWSTD_REINTERPRET_CAST (long, pval), flags); ^ $(TOPDIR)\src\num_put.cpp(725): warning #810: conversion from "const void *" to "unsigned long" may lose significant bits len = __rw_itoa (buf, _RWSTD_REINTERPRET_CAST (unsigned long, pval), ^ > [Sun C++] 64-bit conversion warnings building the library > - > > Key: STDCXX-547 > URL: https://issues.apache.org/jira/browse/STDCXX-547 > Project: C++ Standard Library > Issue Type: Bug > Components: Build >Affects Versions: trunk > Environment: Sun C++ +w, wide mode (-xarch=amd64, -xarch=sparcv9, or > -m64) >Reporter: Martin Sebor >Assignee: Martin Sebor >Priority: Minor > Fix For: 4.2 > > > We get a bunch of 64-bit conversion warnings when building the library in > wide (64-bit) mode with Sun C++ 5.8 and 5.9: > gmake: Entering directory `$(BUILDDIR)/lib' > CC -c -D_RWSTDDEBUG -mt -I$(TOPDIR)/include -I$(BUILDDIR)/include > -library=%none -g -xarch=amd64 +w -errtags -erroff=hidef > $(TOPDIR)/src/assert.cpp > ... > CC -c -D_RWSTDDEBUG -mt -I$(TOPDIR)/include -I$(BUILDDIR)/include > -library=%none -g -xarch=amd64 +w -errtags -erroff=hidef > $(TOPDIR)/src/locale_core.cpp > "$(TOPDIR)/src/locale_core.cpp", line 141: Warning, truncwarn: Conversion of > 64 bit type value to "int" causes truncation. > "$(TOPDIR)/src/locale_core.cpp", line 141: Warning, truncwarn: Conversion of > 64 bit type value to "int" causes truncation. > 2 Warning(s) detected. > ... > CC -c -D_RWSTDDEBUG -mt -I$(TOPDIR)/include -I$(BUILDDIR)/include > -library=%none -g -xarch=amd64 +w -errtags -erroff=hidef > $(TOPDIR)/src/num_get.cpp > "$(TOPDIR)/src/num_get.cpp", line 432: Warning, truncwarn: Conversion of 64 > bit type value to "unsigned" causes truncation. > "$(TOPDIR)/src/num_get.cpp", line 461: Warning, truncwarn: Conversion of 64 > bit type value to "int" causes truncation. > 2 Warning(s) detected. > CC -c -D_RWSTDDEBUG -mt -I$(TOPDIR)/include -I$(BUILDDIR)/include > -library=%none -g -xarch=amd64 +w -errtags -erroff=hidef > $(TOPDIR)/src/num_put.cpp > "$(TOPDIR)/src/num_put.cpp", line 417: Warning, truncwarn: Conversion of 64 > bit type value to "const int" causes truncation. > "$(TOPDIR)/src/num_put.cpp", line 417: Warning, truncwarn: Conversion of 64 > bit type value to "const int" causes truncation. > "$(TOPDIR)/src/num_put.cpp", line 745: Warning, truncwarn: Conversion of 64 > bit type value to "int" causes truncation. > "$(TOPDIR)/src/num_put.cpp", line 772: Warning, truncwarn: Conversion of 64 > bit type value to "int" causes truncation. > "$(TOPDIR)/src/num_put.cpp", line 802: Warning, truncwarn: Conversion of 64 > bit type value to "int" causes truncation. > "$(TOPDIR)/src/num_put.cpp", line 830: Warning, truncwarn: Conversion of 64 > bit type value to "int" causes truncation. > 6 Warning(s) detected. > ... > CC -xar -o libstd.a assert.o atomic-cxx.o bitset.o catalog.o codecvt.o > collate.o ctype.o ctype_bits.o domain_error.o exception.o export.o facet.o > file.o instance.o ios.o ios_bits.o iostore.o iostream.o iso2022.o limits.o > limits_bits.o locale_bits.o locale_body.o locale_classic.o locale_combine.o > locale_core.o locale_eq.o locale_global.o locale_name.o logic_error.o > memattr.o memory.o messages.o mman.o num_get.o num_put.o once.o punct.o > random.o range_error.o runtime_error.o setlocale.o string.o strstream.o > strtol.o ti_collate.o ti_filebuf.o ti_insert_dbl.o ti_insert_int.o > ti_insert_ptr.o ti_ios.o ti_istream.o ti_messages.o ti_money_get.o > ti_money_put.o ti_moneypunct.o ti_num_get.o ti_num_put.o ti_numpunct.o > ti_ostream.o ti_podarray.o ti_streambuf.o ti_string.o ti_stringbuf.o > ti_time_get.o ti_time_put.o ti_wcollate.o ti_wfilebuf.o ti_winsert_dbl.o > ti_winsert_int.o ti_winsert_ptr.o ti_wios.o ti_wistream.o ti_wmessages.o > ti_wmoney_get.o ti_wmoney_put.o ti_wmoneypunct.o ti_wnum_get.o ti_wnum_put.o > ti_wnumpunct.o ti_wostream.o ti_wstreambuf.o ti_wstring.o ti_wstringbuf.o > ti_wtime_get.o ti_wtime_put.o time_get.o time_put.o tmpbuf.o typeinfo.o > valarray.o vecbool.o version.o wcodecvt.o wctype.o > gencat rwstderr.cat $(TOPDIR)/src/rwstderr.msg > gmake: Leaving directory `$(BUILDDIR)/lib' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment t
[jira] Commented: (STDCXX-547) [Sun C++] 64-bit conversion warnings building the library
[ https://issues.apache.org/jira/browse/STDCXX-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526523 ] Farid Zaripov commented on STDCXX-547: -- The similar warnings got when building the library with MSVC 8.0 / x64 platform: file.cpp $(TOPDIR)\src\file.cpp(484) : warning C4244: 'argument' : conversion from '__int64' to 'long', possible loss of data $(TOPDIR)\src\file.cpp(493) : warning C4244: 'argument' : conversion from '__int64' to 'long', possible loss of data $(TOPDIR)\src\file.cpp(508) : warning C4244: 'argument' : conversion from 'unsigned __int64' to 'unsigned int', possible loss of data $(TOPDIR)\src\file.cpp(523) : warning C4244: 'argument' : conversion from 'unsigned __int64' to 'unsigned int', possible loss of data locale_core.cpp $(TOPDIR)\src\locale_core.cpp(141) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data num_put.cpp $(TOPDIR)\src\num_put.cpp(745) : warning C4244: 'argument' : conversion from '__int64' to 'int', possible loss of data $(TOPDIR)\src\num_put.cpp(772) : warning C4244: 'argument' : conversion from '__int64' to 'int', possible loss of data $(TOPDIR)\src\num_put.cpp(802) : warning C4244: 'argument' : conversion from '__int64' to 'int', possible loss of data $(TOPDIR)\src\num_put.cpp(830) : warning C4244: 'argument' : conversion from '__int64' to 'int', possible loss of data ti_num_get.cpp $(TOPDIR)\include\loc/_punct.cc(90) : warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) $(TOPDIR)\include\loc/_punct.h(143) : see reference to function template instantiation '__rw::__rw_istreambuf_iterator __rw::__rw_match_name>(std::istreambuf_iterator<_CharT,_Traits>,std::istreambuf_iterator<_CharT,_Traits>,const char *const *,const unsigned __int64 *,unsigned __int64,unsigned __int64 &,int &,std::ios_base *)' being compiled with [ _CharT=char, _Traits=std::char_traits ] ti_wnum_get.cpp $(TOPDIR)\include\loc/_punct.cc(90) : warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) $(TOPDIR)\include\loc/_punct.h(150) : see reference to function template instantiation '__rw::__rw_wistreambuf_iterator __rw::__rw_match_name>(std::istreambuf_iterator<_CharT,_Traits>,std::istreambuf_iterator<_CharT,_Traits>,const wchar_t *const *,const unsigned __int64 *,unsigned __int64,unsigned __int64 &,int &,std::ios_base *)' being compiled with [ _CharT=wchar_t, _Traits=std::char_traits ] $(TOPDIR)\include\loc/_punct.cc(90) : warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) $(TOPDIR)\include\loc/_num_get.cc(218) : see reference to function template instantiation '_InputIter __rw::__rw_match_name>(_InputIter,_InputIter,const _CharT *const *,const unsigned __int64 *,unsigned __int64,unsigned __int64 &,int &,std::ios_base *)' being compiled with [ _InputIter=std::istreambuf_iterator>, _CharT=char, _Traits=std::char_traits ] $(TOPDIR)\include\loc/_num_get.cc(172) : while compiling class template member function 'std::istreambuf_iterator<_CharT,_Traits> std::num_get<_CharT,_InputIter>::do_get(std::istreambuf_iterator<_CharT,_Traits>,std::istreambuf_iterator<_CharT,_Traits>,std::ios_base &,__rw::__rw_iostate &,bool &) const' with [ _CharT=char, _Traits=std::char_traits, _InputIter=std::istreambuf_iterator> ] $(TOPDIR)\include\loc/_locale.h(346) : see reference to class template instantiation 'std::num_get<_CharT,_InputIter>' being compiled with [ _CharT=char, _InputIter=std::istreambuf_iterator> ] $(TOPDIR)\include\loc/_locale.h(88) : see reference to function template instantiation 'const __rw::__rw_facet *__rw::__rw_get_facet<_Facet>(const std::locale &,const _Facet *)' being compiled with [ _Facet=std::numpunct ] $(TOPDIR)\include\loc/_num_get.cc(196) : see reference to function template instantiation 'const _Facet &std::use_facet>(const std::locale &)' being compiled with [ _Facet=std::numpunct, _CharT=wchar_t ] $(TOPDIR)\include\loc/_num_get.cc(172) : while compiling class template member function 'std::istreambuf_iterator<_CharT,_Traits> std::num_get<_CharT,_InputIter>::do_get(std::istreambuf_iterator<_CharT,_Traits>,std::istreambuf_iterator<_CharT,_Traits>,std::ios_base &,__rw::__rw_iostate &,bool &) const' with [ _CharT=wchar_t, _Traits=std::char_traits, _InputIter=std::istreambuf_iterator> ] $(TOPDIR)\include\loc/_nu
[jira] Closed: (STDCXX-516) Rename generate.bat as configure.bat.
[ https://issues.apache.org/jira/browse/STDCXX-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov closed STDCXX-516. > Rename generate.bat as configure.bat. > - > > Key: STDCXX-516 > URL: https://issues.apache.org/jira/browse/STDCXX-516 > Project: C++ Standard Library > Issue Type: Improvement > Components: Configuration >Affects Versions: 4.1.3 > Environment: All Microsoft Windows platforms >Reporter: Eric Lemings >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2 > > > The generate.bat script does exactly the same thing that conventional > 'configure' scripts do on Unix platforms: it configures the build environment > and generates the necessary build files. Therefore, the filename > 'configure.bat' would more easily identify the purpose of this file to users > accustomed to its Unix counterpart. This filename will not interfere with a > 'configure' script if such a script is added later on. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-516) Rename generate.bat as configure.bat.
[ https://issues.apache.org/jira/browse/STDCXX-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-516. -- Resolution: Fixed Fixed thus: http://svn.apache.org/viewvc?rev=574618&view=rev > Rename generate.bat as configure.bat. > - > > Key: STDCXX-516 > URL: https://issues.apache.org/jira/browse/STDCXX-516 > Project: C++ Standard Library > Issue Type: Improvement > Components: Configuration >Affects Versions: 4.1.3 > Environment: All Microsoft Windows platforms >Reporter: Eric Lemings >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2 > > > The generate.bat script does exactly the same thing that conventional > 'configure' scripts do on Unix platforms: it configures the build environment > and generates the necessary build files. Therefore, the filename > 'configure.bat' would more easily identify the purpose of this file to users > accustomed to its Unix counterpart. This filename will not interfere with a > 'configure' script if such a script is added later on. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-517) No required options for generate.bat script
[ https://issues.apache.org/jira/browse/STDCXX-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-517. -- Resolution: Fixed Fixed thus: http://svn.apache.org/viewvc?rev=574613&view=rev > No required options for generate.bat script > --- > > Key: STDCXX-517 > URL: https://issues.apache.org/jira/browse/STDCXX-517 > Project: C++ Standard Library > Issue Type: Improvement > Components: Configuration >Affects Versions: 4.1.3 > Environment: All Windows platforms >Reporter: Eric Lemings >Assignee: Farid Zaripov > Fix For: 4.2 > > > The generate.bat script currently requires two options: /BUILDDIR and > /CONFIG. Unless there's a valid reason NOT to do so, the generate.bat script > should preset or determine the following values for these options when the > user does not specify their own value. /BUILDDIR should default to the > source directory; that is, the same directory containing the generate.bat > script. For the /CONFIG option, the script should probe the build > environment for all possible/supported Windows compilers currently installed > and then sanity check each one that is found. If it finds no sane compilers, > the script should probably issue a warning and just exit. If only one > compiler is found, configure all distribution files to build with that > compiler. If more than one compiler is found, set the target compiler to the > first one found in predefined order of preference. (This order could be for > instance, MSVC 8, 7, ..., Intel C++ 10, 9, 8, etc, Cygwin GCC, Mingw, > Borland, etc.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-517) No required options for generate.bat script
[ https://issues.apache.org/jira/browse/STDCXX-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov closed STDCXX-517. > No required options for generate.bat script > --- > > Key: STDCXX-517 > URL: https://issues.apache.org/jira/browse/STDCXX-517 > Project: C++ Standard Library > Issue Type: Improvement > Components: Configuration >Affects Versions: 4.1.3 > Environment: All Windows platforms >Reporter: Eric Lemings >Assignee: Farid Zaripov > Fix For: 4.2 > > > The generate.bat script currently requires two options: /BUILDDIR and > /CONFIG. Unless there's a valid reason NOT to do so, the generate.bat script > should preset or determine the following values for these options when the > user does not specify their own value. /BUILDDIR should default to the > source directory; that is, the same directory containing the generate.bat > script. For the /CONFIG option, the script should probe the build > environment for all possible/supported Windows compilers currently installed > and then sanity check each one that is found. If it finds no sane compilers, > the script should probably issue a warning and just exit. If only one > compiler is found, configure all distribution files to build with that > compiler. If more than one compiler is found, set the target compiler to the > first one found in predefined order of preference. (This order could be for > instance, MSVC 8, 7, ..., Intel C++ 10, 9, 8, etc, Cygwin GCC, Mingw, > Borland, etc.) -- 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-520) codecvt1.cpp example exits with exitcode=1
[ https://issues.apache.org/jira/browse/STDCXX-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526440 ] farid edited comment on STDCXX-520 at 9/11/07 5:14 AM: --- The example doesn't fail (crash or something). It's just return 1 to indicate that used locales not available. Added output of the error message thus: http://svn.apache.org/viewvc?rev=574560&view=rev Changed type back to improvement and scheduled for 4.2.1. was (Author: farid): The example doesn't fail (crash or something). It's just return 1 to indicate that used locales not available. Added output of the error message thus: http://svn.apache.org/viewvc?rev=574560&view=rev Changed type back to improvement and scheduled to 4.2.1. > codecvt1.cpp example exits with exitcode=1 > -- > > Key: STDCXX-520 > URL: https://issues.apache.org/jira/browse/STDCXX-520 > Project: C++ Standard Library > Issue Type: Improvement > Components: Examples >Affects Versions: 4.1.3 > Environment: All >Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > > codecvt1.cpp example exits with exitcode=1 because of no requested locales > are installed. > The thread in mailing-list: > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03703.html > -- > codecvt1 should probably be disabled for now (until we figure > out how to get it to work) and it should also be renamed to > something more descriptive. Testing three hardwired encodings > doesn't seem like a good idea for a simple example, so maybe > we could split it up into codecvt-sjis.cpp, codecvt-eucjp, > and codecvt-utf8.cpp. > -- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-520) codecvt1.cpp example exits with exitcode=1
[ https://issues.apache.org/jira/browse/STDCXX-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-520: - Fix Version/s: (was: 4.2) 4.2.1 Issue Type: Improvement (was: Bug) The example doesn't fail (crash or something). It's just return 1 to indicate that used locales not available. Added output of the error message thus: http://svn.apache.org/viewvc?rev=574560&view=rev Changed type back to improvement and scheduled to 4.2.1. > codecvt1.cpp example exits with exitcode=1 > -- > > Key: STDCXX-520 > URL: https://issues.apache.org/jira/browse/STDCXX-520 > Project: C++ Standard Library > Issue Type: Improvement > Components: Examples >Affects Versions: 4.1.3 > Environment: All >Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > > codecvt1.cpp example exits with exitcode=1 because of no requested locales > are installed. > The thread in mailing-list: > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03703.html > -- > codecvt1 should probably be disabled for now (until we figure > out how to get it to work) and it should also be renamed to > something more descriptive. Testing three hardwired encodings > doesn't seem like a good idea for a simple example, so maybe > we could split it up into codecvt-sjis.cpp, codecvt-eucjp, > and codecvt-utf8.cpp. > -- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-508) __rw_catlist vector accessed beyond the last element in third call to catopen() (src/catalog.cpp)
[ https://issues.apache.org/jira/browse/STDCXX-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525435 ] Farid Zaripov commented on STDCXX-508: -- Since this issue is related to STDCXX-542, the regression test for STDCXX-542 was extended to check both issues: http://svn.apache.org/viewvc?rev=573287&view=rev > __rw_catlist vector accessed beyond the last element in third call to > catopen() (src/catalog.cpp) > - > > Key: STDCXX-508 > URL: https://issues.apache.org/jira/browse/STDCXX-508 > Project: C++ Standard Library > Issue Type: Bug > Components: 22. Localization >Affects Versions: 4.1.2 > Environment: All >Reporter: Farid Zaripov >Assignee: Farid Zaripov > Fix For: 4.2 > > > std::vector<__rw_cat*> __rw_catlist initially created with size 2 > (catalog.cpp line 40). > During third call to catopen(), __rw_catlist vector accessed beyond the last > element. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-542) message catalog assert/crash after opening multiple
[
https://issues.apache.org/jira/browse/STDCXX-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525432
]
Farid Zaripov commented on STDCXX-542:
--
The regression tests renamed to 22.locale.messages.stdcxx-542.cpp:
http://svn.apache.org/viewvc?rev=573287&view=rev
> message catalog assert/crash after opening multiple
> ---
>
> Key: STDCXX-542
> URL: https://issues.apache.org/jira/browse/STDCXX-542
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
>Affects Versions: 4.1.2, 4.1.3, 4.1.4
> Environment: Windows
>Reporter: Travis Vitek
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> The below code asserts/crashes reliably on windows, but runs to completion on
> at least one other platform. Note that I copied the rwstdmessages.dll from
> the examples directory to simplify the testcase.
> C:\build\stdcxx\build\msvc-8.0\15d\tests>type t.cpp
> #include
> #include
> #include
> // note same problem occurs even if catalog files are
> // different.
> #ifdef _WIN32
> # define CATALOG0 "rwstdmessages.dll"
> # define CATALOG1 "rwstdmessages.dll"
> #else
> # define CATALOG0 "./rwstdmessages.cat"
> # define CATALOG1 "./rwstdmessages.cat"
> #endif
> int main (int argc, char *argv[])
> {
> typedef std::messages messagesT;
> const std::locale loc;
> const messagesT& msgs =
> std::use_facet(loc);
> const messagesT::catalog cat0 =
> msgs.open (CATALOG0, loc);
> assert(! (cat0 < 0)); // ensure open succeeded
> const messagesT::catalog cat1 =
> msgs.open (CATALOG1, loc);
> assert(! (cat1 < 0)); // ensure open succeeded
> msgs.close (cat1); // crash/assert here
> msgs.close (cat0);
> return 0;
> }
> C:\build\stdcxx\build\msvc-8.0\15d\tests>t
> C:\build\stdcxx\include\rw/_iterbase.h:436: class __rw::__rw_cat *&__thiscall
> __rw::__rw_debug_iter std::allocator >,class __rw::__rw_cat * *,class
> __rw::__rw_cat * *>::operator *(void) const: Assertion '_C_is_dereferenceable
> ()'
> failed.
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-542) message catalog assert/crash after opening multiple
[
https://issues.apache.org/jira/browse/STDCXX-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov closed STDCXX-542.
> message catalog assert/crash after opening multiple
> ---
>
> Key: STDCXX-542
> URL: https://issues.apache.org/jira/browse/STDCXX-542
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
>Affects Versions: 4.1.2, 4.1.3, 4.1.4
> Environment: Windows
>Reporter: Travis Vitek
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> The below code asserts/crashes reliably on windows, but runs to completion on
> at least one other platform. Note that I copied the rwstdmessages.dll from
> the examples directory to simplify the testcase.
> C:\build\stdcxx\build\msvc-8.0\15d\tests>type t.cpp
> #include
> #include
> #include
> // note same problem occurs even if catalog files are
> // different.
> #ifdef _WIN32
> # define CATALOG0 "rwstdmessages.dll"
> # define CATALOG1 "rwstdmessages.dll"
> #else
> # define CATALOG0 "./rwstdmessages.cat"
> # define CATALOG1 "./rwstdmessages.cat"
> #endif
> int main (int argc, char *argv[])
> {
> typedef std::messages messagesT;
> const std::locale loc;
> const messagesT& msgs =
> std::use_facet(loc);
> const messagesT::catalog cat0 =
> msgs.open (CATALOG0, loc);
> assert(! (cat0 < 0)); // ensure open succeeded
> const messagesT::catalog cat1 =
> msgs.open (CATALOG1, loc);
> assert(! (cat1 < 0)); // ensure open succeeded
> msgs.close (cat1); // crash/assert here
> msgs.close (cat0);
> return 0;
> }
> C:\build\stdcxx\build\msvc-8.0\15d\tests>t
> C:\build\stdcxx\include\rw/_iterbase.h:436: class __rw::__rw_cat *&__thiscall
> __rw::__rw_debug_iter std::allocator >,class __rw::__rw_cat * *,class
> __rw::__rw_cat * *>::operator *(void) const: Assertion '_C_is_dereferenceable
> ()'
> failed.
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-542) message catalog assert/crash after opening multiple
[
https://issues.apache.org/jira/browse/STDCXX-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov resolved STDCXX-542.
--
Resolution: Fixed
Fix Version/s: (was: 4.2.1)
4.2
Fixed thus: http://svn.apache.org/viewvc?rev=572979&view=rev
> message catalog assert/crash after opening multiple
> ---
>
> Key: STDCXX-542
> URL: https://issues.apache.org/jira/browse/STDCXX-542
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
>Affects Versions: 4.1.2, 4.1.3, 4.1.4
> Environment: Windows
>Reporter: Travis Vitek
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> The below code asserts/crashes reliably on windows, but runs to completion on
> at least one other platform. Note that I copied the rwstdmessages.dll from
> the examples directory to simplify the testcase.
> C:\build\stdcxx\build\msvc-8.0\15d\tests>type t.cpp
> #include
> #include
> #include
> // note same problem occurs even if catalog files are
> // different.
> #ifdef _WIN32
> # define CATALOG0 "rwstdmessages.dll"
> # define CATALOG1 "rwstdmessages.dll"
> #else
> # define CATALOG0 "./rwstdmessages.cat"
> # define CATALOG1 "./rwstdmessages.cat"
> #endif
> int main (int argc, char *argv[])
> {
> typedef std::messages messagesT;
> const std::locale loc;
> const messagesT& msgs =
> std::use_facet(loc);
> const messagesT::catalog cat0 =
> msgs.open (CATALOG0, loc);
> assert(! (cat0 < 0)); // ensure open succeeded
> const messagesT::catalog cat1 =
> msgs.open (CATALOG1, loc);
> assert(! (cat1 < 0)); // ensure open succeeded
> msgs.close (cat1); // crash/assert here
> msgs.close (cat0);
> return 0;
> }
> C:\build\stdcxx\build\msvc-8.0\15d\tests>t
> C:\build\stdcxx\include\rw/_iterbase.h:436: class __rw::__rw_cat *&__thiscall
> __rw::__rw_debug_iter std::allocator >,class __rw::__rw_cat * *,class
> __rw::__rw_cat * *>::operator *(void) const: Assertion '_C_is_dereferenceable
> ()'
> failed.
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-542) message catalog assert/crash after opening multiple
[
https://issues.apache.org/jira/browse/STDCXX-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525135
]
Farid Zaripov commented on STDCXX-542:
--
The regression test added: http://svn.apache.org/viewvc?rev=572976&view=rev
> message catalog assert/crash after opening multiple
> ---
>
> Key: STDCXX-542
> URL: https://issues.apache.org/jira/browse/STDCXX-542
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
>Affects Versions: 4.1.2, 4.1.3, 4.1.4
> Environment: Windows
>Reporter: Travis Vitek
>Assignee: Farid Zaripov
> Fix For: 4.2.1
>
>
> The below code asserts/crashes reliably on windows, but runs to completion on
> at least one other platform. Note that I copied the rwstdmessages.dll from
> the examples directory to simplify the testcase.
> C:\build\stdcxx\build\msvc-8.0\15d\tests>type t.cpp
> #include
> #include
> #include
> // note same problem occurs even if catalog files are
> // different.
> #ifdef _WIN32
> # define CATALOG0 "rwstdmessages.dll"
> # define CATALOG1 "rwstdmessages.dll"
> #else
> # define CATALOG0 "./rwstdmessages.cat"
> # define CATALOG1 "./rwstdmessages.cat"
> #endif
> int main (int argc, char *argv[])
> {
> typedef std::messages messagesT;
> const std::locale loc;
> const messagesT& msgs =
> std::use_facet(loc);
> const messagesT::catalog cat0 =
> msgs.open (CATALOG0, loc);
> assert(! (cat0 < 0)); // ensure open succeeded
> const messagesT::catalog cat1 =
> msgs.open (CATALOG1, loc);
> assert(! (cat1 < 0)); // ensure open succeeded
> msgs.close (cat1); // crash/assert here
> msgs.close (cat0);
> return 0;
> }
> C:\build\stdcxx\build\msvc-8.0\15d\tests>t
> C:\build\stdcxx\include\rw/_iterbase.h:436: class __rw::__rw_cat *&__thiscall
> __rw::__rw_debug_iter std::allocator >,class __rw::__rw_cat * *,class
> __rw::__rw_cat * *>::operator *(void) const: Assertion '_C_is_dereferenceable
> ()'
> failed.
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-508) __rw_catlist vector accessed beyond the last element in third call to catopen() (src/catalog.cpp)
[ https://issues.apache.org/jira/browse/STDCXX-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov closed STDCXX-508. The regression test added: http://svn.apache.org/viewvc?rev=572976&view=rev > __rw_catlist vector accessed beyond the last element in third call to > catopen() (src/catalog.cpp) > - > > Key: STDCXX-508 > URL: https://issues.apache.org/jira/browse/STDCXX-508 > Project: C++ Standard Library > Issue Type: Bug > Components: 22. Localization >Affects Versions: 4.1.2 > Environment: All >Reporter: Farid Zaripov >Assignee: Farid Zaripov > Fix For: 4.2 > > > std::vector<__rw_cat*> __rw_catlist initially created with size 2 > (catalog.cpp line 40). > During third call to catopen(), __rw_catlist vector accessed beyond the last > element. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-20) [Cygwin] madvise() needs a config test
[ https://issues.apache.org/jira/browse/STDCXX-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523858 ] Farid Zaripov commented on STDCXX-20: - Cygwin has posix_madvise() function: /usr/include/sys/mman.h: ... extern int posix_madvise (void *__addr, size_t __len, int __advice); ... Here is the information about the function: http://www.opengroup.org/onlinepubs/95399/functions/posix_madvise.html Interesting that www.opengroup.org knows nothing about madvise(). There no page http://www.opengroup.org/onlinepubs/95399/functions/madvise.html and madvise() not mentioned at page with description of sys/mman.h: http://www.opengroup.org/onlinepubs/95399/basedefs/sys/mman.h.html Below is a part of the mman.h on RedHat Enterprise Linux 4: #ifdef __USE_BSD /* Advise the system about particular usage patterns the program follows for the region starting at ADDR and extending LEN bytes. */ extern int madvise (void *__addr, size_t __len, int __advice) __THROW; #endif #ifdef __USE_XOPEN2K /* This is the POSIX name for this function. */ extern int posix_madvise (void *__addr, size_t __len, int __advice) __THROW; #endif By default the both functions are defined. Since posix_madvise() is always defined (I suppose that is true), perhaps we should use it instead of madvise() ? > [Cygwin] madvise() needs a config test > -- > > Key: STDCXX-20 > URL: https://issues.apache.org/jira/browse/STDCXX-20 > Project: C++ Standard Library > Issue Type: Bug > Components: Configuration >Affects Versions: 4.1.2, 4.1.3, 4.1.4 > Environment: Cygwin >Reporter: Martin Sebor >Priority: Minor > Fix For: 4.2 > > > From > http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200509.mbox/[EMAIL > PROTECTED]: > Original Message > Subject: Cygwin build > Date: Sun, 11 Sep 2005 08:13:38 -0400 > From: Lance Diduck <[EMAIL PROTECTED]> > Reply-To: stdcxx-dev@incubator.apache.org > To: > Notes on Cygwin build __CYGWIN__ using gcc 3.4.4 BUILDTYPE=11s default modes > [...] > 2. config.h file should have a entry for _RWSTD_NO_MADVISE I modified the > build's config file directly, I'm not sre how to modify the things that > generate the config.h in the first place. > [...] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-77) [MSVC 7.1] operator new doesn't throw std::bad_alloc on failure
[
https://issues.apache.org/jira/browse/STDCXX-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov closed STDCXX-77.
---
Resolution: Won't Fix
This issue won't be fixed for a while.
> [MSVC 7.1] operator new doesn't throw std::bad_alloc on failure
> ---
>
> Key: STDCXX-77
> URL: https://issues.apache.org/jira/browse/STDCXX-77
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 18. Language Support
>Affects Versions: 4.1.2, 4.1.3, 4.1.4
> Environment: MSVC 7.1
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
> Fix For: 4.2
>
> Attachments: opnew.patch
>
>
> $ cat t.cpp && nmake t.exe && ./t
> #include
> #include
> #include
> int main ()
> {
> _CrtSetReportMode (_CRT_WARN, _CRTDBG_MODE_DEBUG);
> _CrtSetReportMode (_CRT_ERROR, _CRTDBG_MODE_DEBUG);
> _CrtSetReportMode (_CRT_ASSERT, _CRTDBG_MODE_DEBUG);
> int success = 0;
> try {
> operator new ((unsigned long)-1024);
> }
> catch (std::bad_alloc&) { success = 1; }
> catch (...) { }
> assert (success);
> }
> Microsoft (R) Program Maintenance Utility Version 7.10.3077
> Copyright (C) Microsoft Corporation. All rights reserved.
> link -nologo /NODEFAULTLIB:msvcprtd /debug
> /LIBPATH:.\..\..\..\..\lib /OUT:t.exe t.obj testx15d_msvc_7_1.lib
> tlt15d_msvc_7_1.lib std15d_msvc_7_1.lib user32.lib
> LINK : LNK6004: t.exe not found or not built by the last incremental link;
> performing full link
> Assertion failed: success, file t.cpp, line 20
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-77) [MSVC 7.1] operator new doesn't throw std::bad_alloc on failure
[
https://issues.apache.org/jira/browse/STDCXX-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-77:
Attachment: opnew.patch
Attached the possible patch.
> [MSVC 7.1] operator new doesn't throw std::bad_alloc on failure
> ---
>
> Key: STDCXX-77
> URL: https://issues.apache.org/jira/browse/STDCXX-77
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 18. Language Support
>Affects Versions: 4.1.2, 4.1.3, 4.1.4
> Environment: MSVC 7.1
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
> Fix For: 4.2
>
> Attachments: opnew.patch
>
>
> $ cat t.cpp && nmake t.exe && ./t
> #include
> #include
> #include
> int main ()
> {
> _CrtSetReportMode (_CRT_WARN, _CRTDBG_MODE_DEBUG);
> _CrtSetReportMode (_CRT_ERROR, _CRTDBG_MODE_DEBUG);
> _CrtSetReportMode (_CRT_ASSERT, _CRTDBG_MODE_DEBUG);
> int success = 0;
> try {
> operator new ((unsigned long)-1024);
> }
> catch (std::bad_alloc&) { success = 1; }
> catch (...) { }
> assert (success);
> }
> Microsoft (R) Program Maintenance Utility Version 7.10.3077
> Copyright (C) Microsoft Corporation. All rights reserved.
> link -nologo /NODEFAULTLIB:msvcprtd /debug
> /LIBPATH:.\..\..\..\..\lib /OUT:t.exe t.obj testx15d_msvc_7_1.lib
> tlt15d_msvc_7_1.lib std15d_msvc_7_1.lib user32.lib
> LINK : LNK6004: t.exe not found or not built by the last incremental link;
> performing full link
> Assertion failed: success, file t.cpp, line 20
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-515) std::basic_streambuf<>::xsputn() writes characters at the end, but not at the current position if reallocation of internal buffer occurs
[
https://issues.apache.org/jira/browse/STDCXX-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov closed STDCXX-515.
The regression test added: http://svn.apache.org/viewvc?rev=570516&view=rev
> std::basic_streambuf<>::xsputn() writes characters at the end, but not at the
> current position if reallocation of internal buffer occurs
>
>
> Key: STDCXX-515
> URL: https://issues.apache.org/jira/browse/STDCXX-515
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
>Affects Versions: 4.2
> Environment: All
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> The test below asserts on i == 512.
> test.cpp:
> --
> #include
> #include
> #include
> int main ()
> {
> for (size_t i = 1; i <= 1024; ++i) {
> std::stringstream strm;
> std::string s (i, 'a');
> strm << s;
> strm.seekp (-1, std::ios::cur);
> s.erase (0, 1);
> strm << "bc";
> s.append ("bc");
> assert (strm.str () == s);
> }
> return 0;
> }
> --
> The test output:
> --
> test: test.cpp:15: int main (): Assertion `strm.str () == s' failed.
> Aborted
> --
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-515) std::basic_streambuf<>::xsputn() writes characters at the end, but not at the current position if reallocation of internal buffer occurs
[
https://issues.apache.org/jira/browse/STDCXX-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov resolved STDCXX-515.
--
Resolution: Fixed
Fixed thus: http://svn.apache.org/viewvc?rev=570514&view=rev
> std::basic_streambuf<>::xsputn() writes characters at the end, but not at the
> current position if reallocation of internal buffer occurs
>
>
> Key: STDCXX-515
> URL: https://issues.apache.org/jira/browse/STDCXX-515
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
>Affects Versions: 4.2
> Environment: All
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> The test below asserts on i == 512.
> test.cpp:
> --
> #include
> #include
> #include
> int main ()
> {
> for (size_t i = 1; i <= 1024; ++i) {
> std::stringstream strm;
> std::string s (i, 'a');
> strm << s;
> strm.seekp (-1, std::ios::cur);
> s.erase (0, 1);
> strm << "bc";
> s.append ("bc");
> assert (strm.str () == s);
> }
> return 0;
> }
> --
> The test output:
> --
> test: test.cpp:15: int main (): Assertion `strm.str () == s' failed.
> Aborted
> --
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-272) [LWG #625] std::string::find_first_of() returns 0 for the empty string
[
https://issues.apache.org/jira/browse/STDCXX-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov resolved STDCXX-272.
--
Resolution: Fixed
Yes. This issue is a part of the STDCXX-466 issue and fixed by patch for
STDCXX-466.
> [LWG #625] std::string::find_first_of() returns 0 for the empty string
> --
>
> Key: STDCXX-272
> URL: https://issues.apache.org/jira/browse/STDCXX-272
> 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
> Fix For: 4.2
>
>
> The program below is expected to run succeffully to completion (since the
> returned value must be less than the size of the string) but instead it
> aborts.
> $ cat t.cpp && nice gmake t && ./t
> #include
> #include
> int main ()
> {
> std::string::size_type xpos =
> std::string ("").find_first_of ("cba", 0, std::string::npos);
> assert (std::string::npos == xpos);
> }
> aCC -c -I/amd/devco/sebor/dev/stdlib/include/ansi -I/usr/include
> -D_RWSTDDEBUG-D_RWSTD_USE_CONFIG -I/amd/devco/sebor/dev/stdlib/include
> -I/build/sebor/aCC-3.70-11d/include
> -I/amd/devco/sebor/dev/stdlib/examples/include -Aa +nostl -g +d +w +W392
> +W655 +W684 +W818 +W819 +W849 t.cpp
> aCC t.o -o t -Aa +nostl -Wl,+s -Wl,+vnocompatwarnings
> -L/build/sebor/aCC-3.70-11d/lib-L/build/sebor/aCC-3.70-11d/lib -lstd11d
> -lm
> 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] Closed: (STDCXX-272) [LWG #625] std::string::find_first_of() returns 0 for the empty string
[
https://issues.apache.org/jira/browse/STDCXX-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov closed STDCXX-272.
> [LWG #625] std::string::find_first_of() returns 0 for the empty string
> --
>
> Key: STDCXX-272
> URL: https://issues.apache.org/jira/browse/STDCXX-272
> 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
> Fix For: 4.2
>
>
> The program below is expected to run succeffully to completion (since the
> returned value must be less than the size of the string) but instead it
> aborts.
> $ cat t.cpp && nice gmake t && ./t
> #include
> #include
> int main ()
> {
> std::string::size_type xpos =
> std::string ("").find_first_of ("cba", 0, std::string::npos);
> assert (std::string::npos == xpos);
> }
> aCC -c -I/amd/devco/sebor/dev/stdlib/include/ansi -I/usr/include
> -D_RWSTDDEBUG-D_RWSTD_USE_CONFIG -I/amd/devco/sebor/dev/stdlib/include
> -I/build/sebor/aCC-3.70-11d/include
> -I/amd/devco/sebor/dev/stdlib/examples/include -Aa +nostl -g +d +w +W392
> +W655 +W684 +W818 +W819 +W849 t.cpp
> aCC t.o -o t -Aa +nostl -Wl,+s -Wl,+vnocompatwarnings
> -L/build/sebor/aCC-3.70-11d/lib-L/build/sebor/aCC-3.70-11d/lib -lstd11d
> -lm
> 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] Updated: (STDCXX-466) basic_string<>::rfind() and basic_string<>::find_xxx() methods throws length_error(), but shouldn't
[ https://issues.apache.org/jira/browse/STDCXX-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-466: - Fix Version/s: 4.2 Affects Version/s: (was: 4.2) 4.1.3 4.1.4 > basic_string<>::rfind() and basic_string<>::find_xxx() methods throws > length_error(), but shouldn't > --- > > Key: STDCXX-466 > URL: https://issues.apache.org/jira/browse/STDCXX-466 > Project: C++ Standard Library > Issue Type: Bug > Components: 21. Strings >Affects Versions: 4.1.3, 4.1.4 > Environment: All >Reporter: Farid Zaripov >Assignee: Farid Zaripov > Fix For: 4.2 > > > The details are here: > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03795.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-272) [LWG #625] std::string::find_first_of() returns 0 for the empty string
[
https://issues.apache.org/jira/browse/STDCXX-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-272:
-
Fix Version/s: 4.2
> [LWG #625] std::string::find_first_of() returns 0 for the empty string
> --
>
> Key: STDCXX-272
> URL: https://issues.apache.org/jira/browse/STDCXX-272
> 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
> Fix For: 4.2
>
>
> The program below is expected to run succeffully to completion (since the
> returned value must be less than the size of the string) but instead it
> aborts.
> $ cat t.cpp && nice gmake t && ./t
> #include
> #include
> int main ()
> {
> std::string::size_type xpos =
> std::string ("").find_first_of ("cba", 0, std::string::npos);
> assert (std::string::npos == xpos);
> }
> aCC -c -I/amd/devco/sebor/dev/stdlib/include/ansi -I/usr/include
> -D_RWSTDDEBUG-D_RWSTD_USE_CONFIG -I/amd/devco/sebor/dev/stdlib/include
> -I/build/sebor/aCC-3.70-11d/include
> -I/amd/devco/sebor/dev/stdlib/examples/include -Aa +nostl -g +d +w +W392
> +W655 +W684 +W818 +W819 +W849 t.cpp
> aCC t.o -o t -Aa +nostl -Wl,+s -Wl,+vnocompatwarnings
> -L/build/sebor/aCC-3.70-11d/lib-L/build/sebor/aCC-3.70-11d/lib -lstd11d
> -lm
> 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] Updated: (STDCXX-455) [Cygwin] localedef errors: fatal error - could not load shell32, Win32 error 487
[ https://issues.apache.org/jira/browse/STDCXX-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-455: - Fix Version/s: (was: 4.2) 4.3 Deffered to 4.3 version. > [Cygwin] localedef errors: fatal error - could not load shell32, Win32 error > 487 > > > Key: STDCXX-455 > URL: https://issues.apache.org/jira/browse/STDCXX-455 > Project: C++ Standard Library > Issue Type: Bug > Components: Locales > Environment: Cygwin >Reporter: Farid Zaripov >Assignee: Farid Zaripov > Fix For: 4.3 > > > ar_IN.UTF-8, de_DE.UTF-8 and en_IN.UTF-8 locales are failed: >5437 [main] localedef 3260 > d:\_projects\stdcxx_working\cygwin_15s\bin\localedef.exe: *** fatal error - > could not load shell32, Win32 error 487 > /bin/sh: line 5: 3260 Hangup ./localedef -w -c -f > /cygdrive/d/_projects/stdcxx_working/etc/nls/charmaps/$cname -i > /cygdrive/d/_projects/stdcxx_working/etc/nls/src/$lname > /cygdrive/d/_projects/stdcxx_working/cygwin_15s/nls/ar_IN.UTF-8 > make: *** [ar_IN.UTF-8] Error 129 > 5 [main] localedef 3444 > d:\_projects\stdcxx_working\cygwin_15s\bin\localedef.exe: *** fatal error - > could not load shell32, Win32 error 487 > /bin/sh: line 5: 3444 Hangup ./localedef -w -c -f > /cygdrive/d/_projects/stdcxx_working/etc/nls/charmaps/$cname -i > /cygdrive/d/_projects/stdcxx_working/etc/nls/src/$lname > /cygdrive/d/_projects/stdcxx_working/cygwin_15s/nls/de_DE.UTF-8 > make: *** [de_DE.UTF-8] Error 129 > 5 [main] localedef 3952 > d:\_projects\stdcxx_working\cygwin_15s\bin\localedef.exe: *** fatal error - > could not load shell32, Win32 error 487 > /bin/sh: line 5: 3952 Hangup ./localedef -w -c -f > /cygdrive/d/_projects/stdcxx_working/etc/nls/charmaps/$cname -i > /cygdrive/d/_projects/stdcxx_working/etc/nls/src/$lname > /cygdrive/d/_projects/stdcxx_working/cygwin_15s/nls/en_IN.UTF-8 > make: *** [en_IN.UTF-8] Error 129 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-517) No required options for generate.bat script
[ https://issues.apache.org/jira/browse/STDCXX-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-517: - Fix Version/s: 4.2 Scheduled to version 4.2. > No required options for generate.bat script > --- > > Key: STDCXX-517 > URL: https://issues.apache.org/jira/browse/STDCXX-517 > Project: C++ Standard Library > Issue Type: Improvement >Affects Versions: 4.1.3 > Environment: All Windows platforms >Reporter: Eric Lemings >Assignee: Farid Zaripov > Fix For: 4.2 > > > The generate.bat script currently requires two options: /BUILDDIR and > /CONFIG. Unless there's a valid reason NOT to do so, the generate.bat script > should preset or determine the following values for these options when the > user does not specify their own value. /BUILDDIR should default to the > source directory; that is, the same directory containing the generate.bat > script. For the /CONFIG option, the script should probe the build > environment for all possible/supported Windows compilers currently installed > and then sanity check each one that is found. If it finds no sane compilers, > the script should probably issue a warning and just exit. If only one > compiler is found, configure all distribution files to build with that > compiler. If more than one compiler is found, set the target compiler to the > first one found in predefined order of preference. (This order could be for > instance, MSVC 8, 7, ..., Intel C++ 10, 9, 8, etc, Cygwin GCC, Mingw, > Borland, etc.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-77) [MSVC 7.1] operator new doesn't throw std::bad_alloc on failure
[
https://issues.apache.org/jira/browse/STDCXX-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-77:
Fix Version/s: 4.2
> [MSVC 7.1] operator new doesn't throw std::bad_alloc on failure
> ---
>
> Key: STDCXX-77
> URL: https://issues.apache.org/jira/browse/STDCXX-77
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 18. Language Support
>Affects Versions: 4.1.2, 4.1.3, 4.1.4
> Environment: MSVC 7.1
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> $ cat t.cpp && nmake t.exe && ./t
> #include
> #include
> #include
> int main ()
> {
> _CrtSetReportMode (_CRT_WARN, _CRTDBG_MODE_DEBUG);
> _CrtSetReportMode (_CRT_ERROR, _CRTDBG_MODE_DEBUG);
> _CrtSetReportMode (_CRT_ASSERT, _CRTDBG_MODE_DEBUG);
> int success = 0;
> try {
> operator new ((unsigned long)-1024);
> }
> catch (std::bad_alloc&) { success = 1; }
> catch (...) { }
> assert (success);
> }
> Microsoft (R) Program Maintenance Utility Version 7.10.3077
> Copyright (C) Microsoft Corporation. All rights reserved.
> link -nologo /NODEFAULTLIB:msvcprtd /debug
> /LIBPATH:.\..\..\..\..\lib /OUT:t.exe t.obj testx15d_msvc_7_1.lib
> tlt15d_msvc_7_1.lib std15d_msvc_7_1.lib user32.lib
> LINK : LNK6004: t.exe not found or not built by the last incremental link;
> performing full link
> Assertion failed: success, file t.cpp, line 20
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-451) Improve the checking of the ANSI C library functions
[ https://issues.apache.org/jira/browse/STDCXX-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-451: - Fix Version/s: 4.3 > Improve the checking of the ANSI C library functions > > > Key: STDCXX-451 > URL: https://issues.apache.org/jira/browse/STDCXX-451 > Project: C++ Standard Library > Issue Type: Improvement > Components: Configuration >Affects Versions: 4.1.2, 4.1.3, 4.1.4 > Environment: All >Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.3 > > > Perform checking of all declarations in one step, and fallback to the > current algorithm is the first attempt failed. > The additional info: > http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200706.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] Assigned: (STDCXX-79) [MSVC 7] operator new doesn't throw on failure
[
https://issues.apache.org/jira/browse/STDCXX-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov reassigned STDCXX-79:
---
Assignee: Farid Zaripov
> [MSVC 7] operator new doesn't throw on failure
> --
>
> Key: STDCXX-79
> URL: https://issues.apache.org/jira/browse/STDCXX-79
> Project: C++ Standard Library
> Issue Type: Bug
> Components: External
>Affects Versions: 4.1.2
> Environment: MSVC 7.0, 7.1
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
>Priority: Critical
>
> The implementation of operaror new in the MSVC 7 runtime library (but not the
> one in the C++ Standard Library, msvcprtd), fails to throw an exception on
> failure and instead returns 0. This works correctly in MSVC 8.
> Here's a reference to the MSVC 7 documentation of their libraries:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_c_run.2d.time_libraries.asp
> $ cat t.cpp && cl /EHsc /MDd t.cpp /c && link /NODEFAULTLIB:msvcprtd t.obj &&
> ./t
> #include
> #include
> #include
> int main ()
> {
> _CrtSetReportMode (_CRT_WARN, _CRTDBG_MODE_DEBUG);
> _CrtSetReportMode (_CRT_ERROR, _CRTDBG_MODE_DEBUG);
> _CrtSetReportMode (_CRT_ASSERT, _CRTDBG_MODE_DEBUG);
> int success = 0;
> try {
> operator new ((unsigned long)-1024);
> }
> catch (std::bad_alloc&) { success = 1; }
> catch (...) { }
> assert (success);
> }
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
> Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
> t.cpp
> Microsoft (R) Incremental Linker Version 7.10.3077
> Copyright (C) Microsoft Corporation. All rights reserved.
> Assertion failed: success, file t.cpp, line 20
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-77) [MSVC 7.1] operator new doesn't throw std::bad_alloc on failure
[
https://issues.apache.org/jira/browse/STDCXX-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523198
]
Farid Zaripov commented on STDCXX-77:
-
The possible way (which disables user to use _set_new_handler() and
_set_new_mode() functions) is install CRT new handler (using
_set_new_handler()) at library initialization and throw std::bad_alloc from
there. This way is described here: http://support.microsoft.com/?kbid=167733
> [MSVC 7.1] operator new doesn't throw std::bad_alloc on failure
> ---
>
> Key: STDCXX-77
> URL: https://issues.apache.org/jira/browse/STDCXX-77
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 18. Language Support
>Affects Versions: 4.1.2, 4.1.3, 4.1.4
> Environment: MSVC 7.1
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
>
> $ cat t.cpp && nmake t.exe && ./t
> #include
> #include
> #include
> int main ()
> {
> _CrtSetReportMode (_CRT_WARN, _CRTDBG_MODE_DEBUG);
> _CrtSetReportMode (_CRT_ERROR, _CRTDBG_MODE_DEBUG);
> _CrtSetReportMode (_CRT_ASSERT, _CRTDBG_MODE_DEBUG);
> int success = 0;
> try {
> operator new ((unsigned long)-1024);
> }
> catch (std::bad_alloc&) { success = 1; }
> catch (...) { }
> assert (success);
> }
> Microsoft (R) Program Maintenance Utility Version 7.10.3077
> Copyright (C) Microsoft Corporation. All rights reserved.
> link -nologo /NODEFAULTLIB:msvcprtd /debug
> /LIBPATH:.\..\..\..\..\lib /OUT:t.exe t.obj testx15d_msvc_7_1.lib
> tlt15d_msvc_7_1.lib std15d_msvc_7_1.lib user32.lib
> LINK : LNK6004: t.exe not found or not built by the last incremental link;
> performing full link
> Assertion failed: success, file t.cpp, line 20
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.
--
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) Access violation while loading libstdxxx.dll in dynamic builds on Cygwin
[ https://issues.apache.org/jira/browse/STDCXX-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-507: - Fix Version/s: 4.2.1 > Access violation while loading libstdxxx.dll in dynamic builds on Cygwin > > > 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 > Environment: gcc 3.4.4/Cygwin >Reporter: Farid Zaripov >Assignee: Farid Zaripov > Fix For: 4.2.1 > > Attachments: 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-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: - Fix Version/s: (was: 4.2) 4.2.1 > 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 >Reporter: Martin Sebor >Assignee: Farid Zaripov >Priority: Critical > Fix For: 4.2.1 > > > 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] Closed: (STDCXX-462) std::time_get example exposes undefined behavior
[
https://issues.apache.org/jira/browse/STDCXX-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov closed STDCXX-462.
> std::time_get example exposes undefined behavior
>
>
> Key: STDCXX-462
> URL: https://issues.apache.org/jira/browse/STDCXX-462
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 4.1.2, 4.1.3
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
>Priority: Critical
> Fix For: 4.2
>
>
> The example program demonstrating the use of the std::time_get facet
> (http://incubator.apache.org/stdcxx/doc/stdlibref/time-get.html) exposes
> undefined behavior. Quoting from the following post
> http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03760.html:
> Martin Sebor wrote:
> > Farid Zaripov wrote:
> [...]
> >> Btw below is a part of the conforming program (taken from
> >> time_get.cpp)?
> >
> > It's not a conforming program. The locale must stay around as
> > long as the last reference to the facet obtained from it. The
> > tests that fail to follow this rule should be changed.
> >
> >>
> >> ---
> >> const std::time_get &tg =
> >> std::use_facet >(std::locale ("C"));
> >>
> >> // Display time_base::dateorder value.
> >> std::cout << "time_base::dateorder == " << tg.date_order () <<
> >> ".\n";
> >> ---
> >>
> >> This fragment fails on Dinkumware STL because of tg.date_order() uses
> >> (internal)
> >> pointer to the destroyed locale object.
> >
> > Right, and that's allowed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-462) std::time_get example exposes undefined behavior
[
https://issues.apache.org/jira/browse/STDCXX-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov resolved STDCXX-462.
--
Resolution: Fixed
Documentation updated thus: http://svn.apache.org/viewvc?rev=570219&view=rev
> std::time_get example exposes undefined behavior
>
>
> Key: STDCXX-462
> URL: https://issues.apache.org/jira/browse/STDCXX-462
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 4.1.2, 4.1.3
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
>Priority: Critical
> Fix For: 4.2
>
>
> The example program demonstrating the use of the std::time_get facet
> (http://incubator.apache.org/stdcxx/doc/stdlibref/time-get.html) exposes
> undefined behavior. Quoting from the following post
> http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03760.html:
> Martin Sebor wrote:
> > Farid Zaripov wrote:
> [...]
> >> Btw below is a part of the conforming program (taken from
> >> time_get.cpp)?
> >
> > It's not a conforming program. The locale must stay around as
> > long as the last reference to the facet obtained from it. The
> > tests that fail to follow this rule should be changed.
> >
> >>
> >> ---
> >> const std::time_get &tg =
> >> std::use_facet >(std::locale ("C"));
> >>
> >> // Display time_base::dateorder value.
> >> std::cout << "time_base::dateorder == " << tg.date_order () <<
> >> ".\n";
> >> ---
> >>
> >> This fragment fails on Dinkumware STL because of tg.date_order() uses
> >> (internal)
> >> pointer to the destroyed locale object.
> >
> > Right, and that's allowed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-375) std::getline() declared in , but should be declared in
[
https://issues.apache.org/jira/browse/STDCXX-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-375:
-
Fix Version/s: (was: 4.2)
4.2.1
Affects Version/s: 4.1.4
Deffered to 4.2.1
> std::getline() declared in , but should be declared in
>
>
> 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
> #include
> 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] Updated: (STDCXX-458) limits example status depends on platform
[ https://issues.apache.org/jira/browse/STDCXX-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-458: - Fix Version/s: 4.2.1 Affects Version/s: 4.1.3 4.1.4 > limits example status depends on platform > - > > Key: STDCXX-458 > URL: https://issues.apache.org/jira/browse/STDCXX-458 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples >Affects Versions: 4.1.2, 4.1.3, 4.1.4 > Environment: All >Reporter: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > > The limits example expected to output inf for Infinity, nan for Quiet NAN and > Signaling NAN. But actually the output depends on the platform (see > STDCXX-51). > The example should produce the inf for Infinity, the qnan for Quiet NAN and > snan for Signaling NAN on all platforms > (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03703.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: - Fix Version/s: 4.2.1 Affects Version/s: 4.1.3 4.1.4 > 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 >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-460) The time_get example expected to output time_base::dateorder == 2 but actually output is time_base::dateorder == 0.
[ https://issues.apache.org/jira/browse/STDCXX-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-460: - Fix Version/s: 4.2.1 Affects Version/s: 4.1.3 4.1.4 > The time_get example expected to output time_base::dateorder == 2 but > actually output is time_base::dateorder == 0. > --- > > Key: STDCXX-460 > URL: https://issues.apache.org/jira/browse/STDCXX-460 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples >Affects Versions: 4.1.2, 4.1.3, 4.1.4 > Environment: All. >Reporter: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > > The time_get example expected to output time_base::dateorder == 2 but > actually output is time_base::dateorder == 0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-248) [Intel C++ 9.1/Windows] bad codegen initializing const POD struct
[
https://issues.apache.org/jira/browse/STDCXX-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov closed STDCXX-248.
Resolution: Fixed
Fix Version/s: trunk
The bug is not reproducible on latest icc 9.1 (Build 20070510Z Package ID:
W_CC_C_9.1.038)
> [Intel C++ 9.1/Windows] bad codegen initializing const POD struct
> -
>
> Key: STDCXX-248
> URL: https://issues.apache.org/jira/browse/STDCXX-248
> Project: C++ Standard Library
> Issue Type: Bug
> Components: External
>Affects Versions: 4.1.3
> Environment: Intel C++ 9.1, Windows
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
>Priority: Minor
> Fix For: trunk
>
>
> The program below is expected to run without assert. When compiled with Intel
> C++ 9.1 on Windows, it's terminated with runtime error instead. Note that
> MSVC++ 7.1 behaves as expected.
> ==
> #include
> struct UserChar
> {
> long double f;
> unsigned char c;
> };
> struct UserInt
> {
> int i_;
> UserChar to_char () const
> {
> const UserChar tmp = { 0, i_ };
> return tmp;
> }
> UserChar to_char2 () const
> {
> UserChar tmp = { 0, i_ };
> return tmp;
> }
> UserChar to_char3 () const
> {
> UserChar tmp = { 0 };
> tmp.c = i_;
> return tmp;
> }
> };
> int main(int argc, char* argv[])
> {
> const char TEST_CHAR = 'a';
> UserInt ui = { TEST_CHAR };
> UserChar uc = ui.to_char ();
> UserChar uc2 = ui.to_char2 ();
> UserChar uc3 = ui.to_char3 ();
> assert (TEST_CHAR == uc.c && TEST_CHAR == uc2.c && TEST_CHAR == uc3.c);
> return 0;
> }
> ==
> icl icl91_test.cpp
> Intel(R) C++ Compiler for 32-bit applications, Version 9.1Build 20060323Z
> Copyright (C) 1985-2006 Intel Corporation. All rights reserved.
> icl91_test.cpp
> Microsoft (R) Incremental Linker Version 7.10.3077
> Copyright (C) Microsoft Corporation. All rights reserved.
> -out:icl91_test.exe
> icl91_test.obj
> ==
> icl91_test.exe
> Assertion failed: TEST_CHAR == uc.c && TEST_CHAR == uc2.c && TEST_CHAR ==
> uc3.c,
> file icl91_test.cpp, line 43
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.
> ==
> Generated assembler code:
> UserChar to_char () const
> 00439A44 pushebp
> 00439A45 mov ebp,esp
> 00439A47 pushesi
> 00439A48 mov dword ptr [ebp-4],ecx
> const UserChar tmp = { 0, i_ };
> 00439A4B fldz
> 00439A4D mov eax,dword ptr [ebp+8]
> 00439A50 fstpqword ptr [eax]
> return tmp;
> 00439A52 mov eax,dword ptr [ebp+8]
> 00439A55 leave
> 00439A56 ret 4
> tmp.c is not initialized by value this->i_ and as a result it contains a
> random value.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-248) [Intel C++ 9.1/Windows] bad codegen initializing const POD struct
[
https://issues.apache.org/jira/browse/STDCXX-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-248:
-
Fix Version/s: (was: trunk)
4.2
> [Intel C++ 9.1/Windows] bad codegen initializing const POD struct
> -
>
> Key: STDCXX-248
> URL: https://issues.apache.org/jira/browse/STDCXX-248
> Project: C++ Standard Library
> Issue Type: Bug
> Components: External
>Affects Versions: 4.1.3
> Environment: Intel C++ 9.1, Windows
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
>Priority: Minor
> Fix For: 4.2
>
>
> The program below is expected to run without assert. When compiled with Intel
> C++ 9.1 on Windows, it's terminated with runtime error instead. Note that
> MSVC++ 7.1 behaves as expected.
> ==
> #include
> struct UserChar
> {
> long double f;
> unsigned char c;
> };
> struct UserInt
> {
> int i_;
> UserChar to_char () const
> {
> const UserChar tmp = { 0, i_ };
> return tmp;
> }
> UserChar to_char2 () const
> {
> UserChar tmp = { 0, i_ };
> return tmp;
> }
> UserChar to_char3 () const
> {
> UserChar tmp = { 0 };
> tmp.c = i_;
> return tmp;
> }
> };
> int main(int argc, char* argv[])
> {
> const char TEST_CHAR = 'a';
> UserInt ui = { TEST_CHAR };
> UserChar uc = ui.to_char ();
> UserChar uc2 = ui.to_char2 ();
> UserChar uc3 = ui.to_char3 ();
> assert (TEST_CHAR == uc.c && TEST_CHAR == uc2.c && TEST_CHAR == uc3.c);
> return 0;
> }
> ==
> icl icl91_test.cpp
> Intel(R) C++ Compiler for 32-bit applications, Version 9.1Build 20060323Z
> Copyright (C) 1985-2006 Intel Corporation. All rights reserved.
> icl91_test.cpp
> Microsoft (R) Incremental Linker Version 7.10.3077
> Copyright (C) Microsoft Corporation. All rights reserved.
> -out:icl91_test.exe
> icl91_test.obj
> ==
> icl91_test.exe
> Assertion failed: TEST_CHAR == uc.c && TEST_CHAR == uc2.c && TEST_CHAR ==
> uc3.c,
> file icl91_test.cpp, line 43
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.
> ==
> Generated assembler code:
> UserChar to_char () const
> 00439A44 pushebp
> 00439A45 mov ebp,esp
> 00439A47 pushesi
> 00439A48 mov dword ptr [ebp-4],ecx
> const UserChar tmp = { 0, i_ };
> 00439A4B fldz
> 00439A4D mov eax,dword ptr [ebp+8]
> 00439A50 fstpqword ptr [eax]
> return tmp;
> 00439A52 mov eax,dword ptr [ebp+8]
> 00439A55 leave
> 00439A56 ret 4
> tmp.c is not initialized by value this->i_ and as a result it contains a
> random value.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-248) [Intel C++ 9.1/Windows] bad codegen initializing const POD struct
[
https://issues.apache.org/jira/browse/STDCXX-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov reassigned STDCXX-248:
Assignee: Farid Zaripov
> [Intel C++ 9.1/Windows] bad codegen initializing const POD struct
> -
>
> Key: STDCXX-248
> URL: https://issues.apache.org/jira/browse/STDCXX-248
> Project: C++ Standard Library
> Issue Type: Bug
> Components: External
>Affects Versions: 4.1.3
> Environment: Intel C++ 9.1, Windows
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
>Priority: Minor
>
> The program below is expected to run without assert. When compiled with Intel
> C++ 9.1 on Windows, it's terminated with runtime error instead. Note that
> MSVC++ 7.1 behaves as expected.
> ==
> #include
> struct UserChar
> {
> long double f;
> unsigned char c;
> };
> struct UserInt
> {
> int i_;
> UserChar to_char () const
> {
> const UserChar tmp = { 0, i_ };
> return tmp;
> }
> UserChar to_char2 () const
> {
> UserChar tmp = { 0, i_ };
> return tmp;
> }
> UserChar to_char3 () const
> {
> UserChar tmp = { 0 };
> tmp.c = i_;
> return tmp;
> }
> };
> int main(int argc, char* argv[])
> {
> const char TEST_CHAR = 'a';
> UserInt ui = { TEST_CHAR };
> UserChar uc = ui.to_char ();
> UserChar uc2 = ui.to_char2 ();
> UserChar uc3 = ui.to_char3 ();
> assert (TEST_CHAR == uc.c && TEST_CHAR == uc2.c && TEST_CHAR == uc3.c);
> return 0;
> }
> ==
> icl icl91_test.cpp
> Intel(R) C++ Compiler for 32-bit applications, Version 9.1Build 20060323Z
> Copyright (C) 1985-2006 Intel Corporation. All rights reserved.
> icl91_test.cpp
> Microsoft (R) Incremental Linker Version 7.10.3077
> Copyright (C) Microsoft Corporation. All rights reserved.
> -out:icl91_test.exe
> icl91_test.obj
> ==
> icl91_test.exe
> Assertion failed: TEST_CHAR == uc.c && TEST_CHAR == uc2.c && TEST_CHAR ==
> uc3.c,
> file icl91_test.cpp, line 43
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.
> ==
> Generated assembler code:
> UserChar to_char () const
> 00439A44 pushebp
> 00439A45 mov ebp,esp
> 00439A47 pushesi
> 00439A48 mov dword ptr [ebp-4],ecx
> const UserChar tmp = { 0, i_ };
> 00439A4B fldz
> 00439A4D mov eax,dword ptr [ebp+8]
> 00439A50 fstpqword ptr [eax]
> return tmp;
> 00439A52 mov eax,dword ptr [ebp+8]
> 00439A55 leave
> 00439A56 ret 4
> tmp.c is not initialized by value this->i_ and as a result it contains a
> random value.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-538) ATOMIC_OPS.cpp test fails to link (unresolved external symbol: _InterlockedIncrement)
[ https://issues.apache.org/jira/browse/STDCXX-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov closed STDCXX-538. > ATOMIC_OPS.cpp test fails to link (unresolved external symbol: > _InterlockedIncrement) > - > > Key: STDCXX-538 > URL: https://issues.apache.org/jira/browse/STDCXX-538 > Project: C++ Standard Library > Issue Type: Bug > Components: Configuration >Affects Versions: 4.1.3, 4.1.4 > Environment: x64 Windows >Reporter: Farid Zaripov >Assignee: Farid Zaripov > Fix For: 4.2 > > > ATOMIC_OPS.cpp configuration test failed on MSVC8.0-x64 due to undefined > external symbol _InterlockedIncrement. > Because of this _RWSTD_NO_ATOMIC_OPS macro has been #defined in config.h. > The InterlockedIncrement() function defined only in Win32 platform (located > in kernel32.dll). At x64 platform this function is declared, but kernel32.dll > doesn't exports this function. The MSVC8 injects code of the function instead > of call (so called intrinsic function). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-538) ATOMIC_OPS.cpp test fails to link (unresolved external symbol: _InterlockedIncrement)
[ https://issues.apache.org/jira/browse/STDCXX-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-538. -- Resolution: Fixed Fixed thus: http://svn.apache.org/viewvc?rev=570199&view=rev > ATOMIC_OPS.cpp test fails to link (unresolved external symbol: > _InterlockedIncrement) > - > > Key: STDCXX-538 > URL: https://issues.apache.org/jira/browse/STDCXX-538 > Project: C++ Standard Library > Issue Type: Bug > Components: Configuration >Affects Versions: 4.1.3, 4.1.4 > Environment: x64 Windows >Reporter: Farid Zaripov >Assignee: Farid Zaripov > Fix For: 4.2 > > > ATOMIC_OPS.cpp configuration test failed on MSVC8.0-x64 due to undefined > external symbol _InterlockedIncrement. > Because of this _RWSTD_NO_ATOMIC_OPS macro has been #defined in config.h. > The InterlockedIncrement() function defined only in Win32 platform (located > in kernel32.dll). At x64 platform this function is declared, but kernel32.dll > doesn't exports this function. The MSVC8 injects code of the function instead > of call (so called intrinsic function). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-538) ATOMIC_OPS.cpp test fails to link (unresolved external symbol: _InterlockedIncrement)
ATOMIC_OPS.cpp test fails to link (unresolved external symbol: _InterlockedIncrement) - Key: STDCXX-538 URL: https://issues.apache.org/jira/browse/STDCXX-538 Project: C++ Standard Library Issue Type: Bug Components: Configuration Affects Versions: 4.1.4, 4.1.3 Environment: x64 Windows Reporter: Farid Zaripov Assignee: Farid Zaripov Fix For: 4.2 ATOMIC_OPS.cpp configuration test failed on MSVC8.0-x64 due to undefined external symbol _InterlockedIncrement. Because of this _RWSTD_NO_ATOMIC_OPS macro has been #defined in config.h. The InterlockedIncrement() function defined only in Win32 platform (located in kernel32.dll). At x64 platform this function is declared, but kernel32.dll doesn't exports this function. The MSVC8 injects code of the function instead of call (so called intrinsic function). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-517) No required options for generate.bat script
[ https://issues.apache.org/jira/browse/STDCXX-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521140 ] Farid Zaripov commented on STDCXX-517: -- This is good improvement. > No required options for generate.bat script > --- > > Key: STDCXX-517 > URL: https://issues.apache.org/jira/browse/STDCXX-517 > Project: C++ Standard Library > Issue Type: Improvement >Affects Versions: 4.2 > Environment: All Windows platforms >Reporter: Eric Lemings >Assignee: Farid Zaripov > Fix For: 4.1.2 > > > The generate.bat script currently requires two options: /BUILDDIR and > /CONFIG. Unless there's a valid reason NOT to do so, the generate.bat script > should preset or determine the following values for these options when the > user does not specify their own value. /BUILDDIR should default to the > source directory; that is, the same directory containing the generate.bat > script. For the /CONFIG option, the script should probe the build > environment for all possible/supported Windows compilers currently installed > and then sanity check each one that is found. If it finds no sane compilers, > the script should probably issue a warning and just exit. If only one > compiler is found, configure all distribution files to build with that > compiler. If more than one compiler is found, set the target compiler to the > first one found in predefined order of preference. (This order could be for > instance, MSVC 8, 7, ..., Intel C++ 10, 9, 8, etc, Cygwin GCC, Mingw, > Borland, etc.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-519) [MSVC 7.1 fails to compile fmtflags_manip.cpp example
[ https://issues.apache.org/jira/browse/STDCXX-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov closed STDCXX-519. > [MSVC 7.1 fails to compile fmtflags_manip.cpp example > - > > Key: STDCXX-519 > URL: https://issues.apache.org/jira/browse/STDCXX-519 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples > Environment: MSVC 7.1 >Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2 > > > The compiler issues the errors: > -- > Compiling... > fmtflags_manip.cpp > \stdcxx\trunk\examples\manual\fmtflags_manip.cpp(45) : error C2065: > '__rw_fmtflags' : undeclared identifier > \stdcxx\trunk\examples\manual\fmtflags_manip.cpp(45) : error C2064: term does > not evaluate to a function taking 0 arguments > -- > Created corresponding issue on Microsoft feedback page: > https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=267488 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-519) [MSVC 7.1 fails to compile fmtflags_manip.cpp example
[ https://issues.apache.org/jira/browse/STDCXX-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-519. -- Resolution: Fixed Fix Version/s: 4.2 I was wrong, the typedef doesn't helps. Fixed thus: http://svn.apache.org/viewvc?view=rev&revision=565279 > [MSVC 7.1 fails to compile fmtflags_manip.cpp example > - > > Key: STDCXX-519 > URL: https://issues.apache.org/jira/browse/STDCXX-519 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples > Environment: MSVC 7.1 >Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2 > > > The compiler issues the errors: > -- > Compiling... > fmtflags_manip.cpp > \stdcxx\trunk\examples\manual\fmtflags_manip.cpp(45) : error C2065: > '__rw_fmtflags' : undeclared identifier > \stdcxx\trunk\examples\manual\fmtflags_manip.cpp(45) : error C2064: term does > not evaluate to a function taking 0 arguments > -- > Created corresponding issue on Microsoft feedback page: > https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=267488 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-519) [MSVC 7.1 fails to compile fmtflags_manip.cpp example
[ https://issues.apache.org/jira/browse/STDCXX-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov reassigned STDCXX-519: Assignee: Farid Zaripov > [MSVC 7.1 fails to compile fmtflags_manip.cpp example > - > > Key: STDCXX-519 > URL: https://issues.apache.org/jira/browse/STDCXX-519 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples > Environment: MSVC 7.1 >Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > > The compiler issues the errors: > -- > Compiling... > fmtflags_manip.cpp > \stdcxx\trunk\examples\manual\fmtflags_manip.cpp(45) : error C2065: > '__rw_fmtflags' : undeclared identifier > \stdcxx\trunk\examples\manual\fmtflags_manip.cpp(45) : error C2064: term does > not evaluate to a function taking 0 arguments > -- > Created corresponding issue on Microsoft feedback page: > https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=267488 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-519) [MSVC 7.1 fails to compile fmtflags_manip.cpp example
[ https://issues.apache.org/jira/browse/STDCXX-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519354 ] Farid Zaripov commented on STDCXX-519: -- 1) Initialization the object to a value helps, but how about the thing that "example should be generic and there is no needs to workaround for one broken compiler"? :) 2) why saved_ (std::ios_base::fmtflags (-1)) but not saved_ (std::ios_base::fmtflags (0)), (the default initialization is zero initialization)? 3) typedef also helps. > [MSVC 7.1 fails to compile fmtflags_manip.cpp example > - > > Key: STDCXX-519 > URL: https://issues.apache.org/jira/browse/STDCXX-519 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples > Environment: MSVC 7.1 >Reporter: Farid Zaripov >Priority: Minor > > The compiler issues the errors: > -- > Compiling... > fmtflags_manip.cpp > \stdcxx\trunk\examples\manual\fmtflags_manip.cpp(45) : error C2065: > '__rw_fmtflags' : undeclared identifier > \stdcxx\trunk\examples\manual\fmtflags_manip.cpp(45) : error C2064: term does > not evaluate to a function taking 0 arguments > -- > Created corresponding issue on Microsoft feedback page: > https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=267488 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-520) codecvt1.cpp example exits with exitcode=1
codecvt1.cpp example exits with exitcode=1 -- Key: STDCXX-520 URL: https://issues.apache.org/jira/browse/STDCXX-520 Project: C++ Standard Library Issue Type: Improvement Components: Examples Environment: All Reporter: Farid Zaripov Priority: Minor codecvt1.cpp example exits with exitcode=1 because of no requested locales are installed. The thread in mailing-list: http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03703.html -- codecvt1 should probably be disabled for now (until we figure out how to get it to work) and it should also be renamed to something more descriptive. Testing three hardwired encodings doesn't seem like a good idea for a simple example, so maybe we could split it up into codecvt-sjis.cpp, codecvt-eucjp, and codecvt-utf8.cpp. -- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-519) [MSVC 7.1 fails to compile fmtflags_manip.cpp example
[MSVC 7.1 fails to compile fmtflags_manip.cpp example - Key: STDCXX-519 URL: https://issues.apache.org/jira/browse/STDCXX-519 Project: C++ Standard Library Issue Type: Bug Components: Examples Environment: MSVC 7.1 Reporter: Farid Zaripov Priority: Minor The compiler issues the errors: -- Compiling... fmtflags_manip.cpp \stdcxx\trunk\examples\manual\fmtflags_manip.cpp(45) : error C2065: '__rw_fmtflags' : undeclared identifier \stdcxx\trunk\examples\manual\fmtflags_manip.cpp(45) : error C2064: term does not evaluate to a function taking 0 arguments -- Created corresponding issue on Microsoft feedback page: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=267488 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-515) std::basic_streambuf<>::xsputn() writes characters at the end, but not at the current position if reallocation of internal buffer occurs
[
https://issues.apache.org/jira/browse/STDCXX-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-515:
-
Affects Version/s: (was: 4.1.3)
4.2
Corrected "Affects version/s" field.
> std::basic_streambuf<>::xsputn() writes characters at the end, but not at the
> current position if reallocation of internal buffer occurs
>
>
> Key: STDCXX-515
> URL: https://issues.apache.org/jira/browse/STDCXX-515
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
>Affects Versions: 4.2
> Environment: All
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> The test below asserts on i == 512.
> test.cpp:
> --
> #include
> #include
> #include
> int main ()
> {
> for (size_t i = 1; i <= 1024; ++i) {
> std::stringstream strm;
> std::string s (i, 'a');
> strm << s;
> strm.seekp (-1, std::ios::cur);
> s.erase (0, 1);
> strm << "bc";
> s.append ("bc");
> assert (strm.str () == s);
> }
> return 0;
> }
> --
> The test output:
> --
> test: test.cpp:15: int main (): Assertion `strm.str () == s' failed.
> Aborted
> --
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-514) basic_stringbuf<>::str() deallocating external buffer
[
https://issues.apache.org/jira/browse/STDCXX-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov closed STDCXX-514.
Resolution: Fixed
Corrected "Affects version/s" field.
> basic_stringbuf<>::str() deallocating external buffer
> -
>
> Key: STDCXX-514
> URL: https://issues.apache.org/jira/browse/STDCXX-514
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
>Affects Versions: 4.2
> Environment: All
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> The program below aborts due to deallocating the external buffer extbuf.
> test.cpp:
> --
> #include // for stringbuf
> #include// for allocator
> #include // for assert()
> char extbuf [3];
> struct MyAlloc : std::allocator
> {
> pointer allocate (size_type __n, std::allocator::const_pointer = 0)
> {
> return new char [__n];
> }
> void deallocate (pointer __p, size_type)
> {
> assert (extbuf != __p);
> delete [] __p;
> }
> };
> int main ()
> {
> std::basic_stringbuf , MyAlloc> sbuf;
> sbuf.pubsetbuf (extbuf, sizeof (extbuf));
> const char* str = "abcdef";
> sbuf.str (str);
> assert (sbuf.str () == str);
> return 0;
> }
> --
> The test output:
> --
> test: test.cpp:16: void MyAlloc::deallocate(char*, unsigned int): Assertion
> `extbuf != __p' failed.
> Aborted
> --
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-514) basic_stringbuf<>::str() deallocating external buffer
[
https://issues.apache.org/jira/browse/STDCXX-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-514:
-
Affects Version/s: (was: 4.1.3)
4.2
> basic_stringbuf<>::str() deallocating external buffer
> -
>
> Key: STDCXX-514
> URL: https://issues.apache.org/jira/browse/STDCXX-514
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
>Affects Versions: 4.2
> Environment: All
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> The program below aborts due to deallocating the external buffer extbuf.
> test.cpp:
> --
> #include // for stringbuf
> #include// for allocator
> #include // for assert()
> char extbuf [3];
> struct MyAlloc : std::allocator
> {
> pointer allocate (size_type __n, std::allocator::const_pointer = 0)
> {
> return new char [__n];
> }
> void deallocate (pointer __p, size_type)
> {
> assert (extbuf != __p);
> delete [] __p;
> }
> };
> int main ()
> {
> std::basic_stringbuf , MyAlloc> sbuf;
> sbuf.pubsetbuf (extbuf, sizeof (extbuf));
> const char* str = "abcdef";
> sbuf.str (str);
> assert (sbuf.str () == str);
> return 0;
> }
> --
> The test output:
> --
> test: test.cpp:16: void MyAlloc::deallocate(char*, unsigned int): Assertion
> `extbuf != __p' failed.
> Aborted
> --
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (STDCXX-514) basic_stringbuf<>::str() deallocating external buffer
[
https://issues.apache.org/jira/browse/STDCXX-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov reopened STDCXX-514:
--
> basic_stringbuf<>::str() deallocating external buffer
> -
>
> Key: STDCXX-514
> URL: https://issues.apache.org/jira/browse/STDCXX-514
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
>Affects Versions: 4.2
> Environment: All
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> The program below aborts due to deallocating the external buffer extbuf.
> test.cpp:
> --
> #include // for stringbuf
> #include// for allocator
> #include // for assert()
> char extbuf [3];
> struct MyAlloc : std::allocator
> {
> pointer allocate (size_type __n, std::allocator::const_pointer = 0)
> {
> return new char [__n];
> }
> void deallocate (pointer __p, size_type)
> {
> assert (extbuf != __p);
> delete [] __p;
> }
> };
> int main ()
> {
> std::basic_stringbuf , MyAlloc> sbuf;
> sbuf.pubsetbuf (extbuf, sizeof (extbuf));
> const char* str = "abcdef";
> sbuf.str (str);
> assert (sbuf.str () == str);
> return 0;
> }
> --
> The test output:
> --
> test: test.cpp:16: void MyAlloc::deallocate(char*, unsigned int): Assertion
> `extbuf != __p' failed.
> Aborted
> --
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-515) std::basic_streambuf<>::xsputn() writes characters at the end, but not at the current position if reallocation of internal buffer occurs
std::basic_streambuf<>::xsputn() writes characters at the end, but not at the
current position if reallocation of internal buffer occurs
Key: STDCXX-515
URL: https://issues.apache.org/jira/browse/STDCXX-515
Project: C++ Standard Library
Issue Type: Bug
Components: 27. Input/Output
Affects Versions: 4.1.3
Environment: All
Reporter: Farid Zaripov
Assignee: Farid Zaripov
Fix For: 4.2
The test below asserts on i == 512.
test.cpp:
--
#include
#include
#include
int main ()
{
for (size_t i = 1; i <= 1024; ++i) {
std::stringstream strm;
std::string s (i, 'a');
strm << s;
strm.seekp (-1, std::ios::cur);
s.erase (0, 1);
strm << "bc";
s.append ("bc");
assert (strm.str () == s);
}
return 0;
}
--
The test output:
--
test: test.cpp:15: int main (): Assertion `strm.str () == s' failed.
Aborted
--
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-514) basic_stringbuf<>::str() deallocating external buffer
[
https://issues.apache.org/jira/browse/STDCXX-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov closed STDCXX-514.
The regression test added: http://svn.apache.org/viewvc?view=rev&rev=564228
> basic_stringbuf<>::str() deallocating external buffer
> -
>
> Key: STDCXX-514
> URL: https://issues.apache.org/jira/browse/STDCXX-514
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
>Affects Versions: 4.1.3
> Environment: All
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> The program below aborts due to deallocating the external buffer extbuf.
> test.cpp:
> --
> #include // for stringbuf
> #include// for allocator
> #include // for assert()
> char extbuf [3];
> struct MyAlloc : std::allocator
> {
> pointer allocate (size_type __n, std::allocator::const_pointer = 0)
> {
> return new char [__n];
> }
> void deallocate (pointer __p, size_type)
> {
> assert (extbuf != __p);
> delete [] __p;
> }
> };
> int main ()
> {
> std::basic_stringbuf , MyAlloc> sbuf;
> sbuf.pubsetbuf (extbuf, sizeof (extbuf));
> const char* str = "abcdef";
> sbuf.str (str);
> assert (sbuf.str () == str);
> return 0;
> }
> --
> The test output:
> --
> test: test.cpp:16: void MyAlloc::deallocate(char*, unsigned int): Assertion
> `extbuf != __p' failed.
> Aborted
> --
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-514) basic_stringbuf<>::str() deallocating external buffer
[
https://issues.apache.org/jira/browse/STDCXX-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov resolved STDCXX-514.
--
Resolution: Fixed
Fixed thus: http://svn.apache.org/viewvc?view=rev&rev=564213
> basic_stringbuf<>::str() deallocating external buffer
> -
>
> Key: STDCXX-514
> URL: https://issues.apache.org/jira/browse/STDCXX-514
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
>Affects Versions: 4.1.3
> Environment: All
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> The program below aborts due to deallocating the external buffer extbuf.
> test.cpp:
> --
> #include // for stringbuf
> #include// for allocator
> #include // for assert()
> char extbuf [3];
> struct MyAlloc : std::allocator
> {
> pointer allocate (size_type __n, std::allocator::const_pointer = 0)
> {
> return new char [__n];
> }
> void deallocate (pointer __p, size_type)
> {
> assert (extbuf != __p);
> delete [] __p;
> }
> };
> int main ()
> {
> std::basic_stringbuf , MyAlloc> sbuf;
> sbuf.pubsetbuf (extbuf, sizeof (extbuf));
> const char* str = "abcdef";
> sbuf.str (str);
> assert (sbuf.str () == str);
> return 0;
> }
> --
> The test output:
> --
> test: test.cpp:16: void MyAlloc::deallocate(char*, unsigned int): Assertion
> `extbuf != __p' failed.
> Aborted
> --
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-514) basic_stringbuf<>::str() deallocating external buffer
[
https://issues.apache.org/jira/browse/STDCXX-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-514:
-
Description:
The program below aborts due to deallocating the external buffer extbuf.
test.cpp:
--
#include // for stringbuf
#include// for allocator
#include // for assert()
char extbuf [3];
struct MyAlloc : std::allocator
{
pointer allocate (size_type __n, std::allocator::const_pointer = 0) {
return new char [__n];
}
void deallocate (pointer __p, size_type)
{
assert (extbuf != __p);
delete [] __p;
}
};
int main ()
{
std::basic_stringbuf , MyAlloc> sbuf;
sbuf.pubsetbuf (extbuf, sizeof (extbuf));
const char* str = "abcdef";
sbuf.str (str);
assert (sbuf.str () == str);
return 0;
}
--
The test output:
--
test: test.cpp:16: void MyAlloc::deallocate(char*, unsigned int): Assertion
`extbuf != __p' failed.
Aborted
--
was:
The program below aborts due to deallocating the external buffer extbuf.
test.cpp:
--
#include // for stringbuf
#include// for allocator
#include // for assert()
struct MyAlloc : std::allocator
{
static char __buf [512];
static size_type __used_n;
pointer allocate (size_type __n, std::allocator::const_pointer = 0) {
assert (!__used_n);
assert (sizeof (__buf) >= __n * sizeof (value_type));
__used_n = __n;
return __buf;
}
void deallocate (pointer __p, size_type __n)
{
if (__p) {
assert (__buf == __p);
assert (__used_n == __n);
__used_n = 0;
}
}
};
MyAlloc::size_type MyAlloc::__used_n = 0;
char MyAlloc::__buf [512];
int main ()
{
char extbuf [3];
std::basic_stringbuf , MyAlloc> sbuf;
sbuf.pubsetbuf (extbuf, sizeof (extbuf));
// stdcxx extension used: basic_stringbuf::str (const char*, size_t)
sbuf.str ("abcdef", 6);
return 0;
}
--
The test output:
--
test: test.cpp:21: void MyAlloc::deallocate(char*, unsigned int): Assertion
`__buf == __p' failed.
Aborted
--
Simplified test case.
> basic_stringbuf<>::str() deallocating external buffer
> -
>
> Key: STDCXX-514
> URL: https://issues.apache.org/jira/browse/STDCXX-514
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
>Affects Versions: 4.1.3
> Environment: All
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> The program below aborts due to deallocating the external buffer extbuf.
> test.cpp:
> --
> #include // for stringbuf
> #include// for allocator
> #include // for assert()
> char extbuf [3];
> struct MyAlloc : std::allocator
> {
> pointer allocate (size_type __n, std::allocator::const_pointer = 0)
> {
> return new char [__n];
> }
> void deallocate (pointer __p, size_type)
> {
> assert (extbuf != __p);
> delete [] __p;
> }
> };
> int main ()
> {
> std::basic_stringbuf , MyAlloc> sbuf;
> sbuf.pubsetbuf (extbuf, sizeof (extbuf));
> const char* str = "abcdef";
> sbuf.str (str);
> assert (sbuf.str () == str);
> return 0;
> }
> --
> The test output:
> --
> test: test.cpp:16: void MyAlloc::deallocate(char*, unsigned int): Assertion
> `extbuf != __p' failed.
> Aborted
> --
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-514) basic_stringbuf<>::str() deallocating external buffer
basic_stringbuf<>::str() deallocating external buffer
-
Key: STDCXX-514
URL: https://issues.apache.org/jira/browse/STDCXX-514
Project: C++ Standard Library
Issue Type: Bug
Components: 27. Input/Output
Affects Versions: 4.1.3
Environment: All
Reporter: Farid Zaripov
Assignee: Farid Zaripov
Fix For: 4.2
The program below aborts due to deallocating the external buffer extbuf.
test.cpp:
--
#include // for stringbuf
#include// for allocator
#include // for assert()
struct MyAlloc : std::allocator
{
static char __buf [512];
static size_type __used_n;
pointer allocate (size_type __n, std::allocator::const_pointer = 0) {
assert (!__used_n);
assert (sizeof (__buf) >= __n * sizeof (value_type));
__used_n = __n;
return __buf;
}
void deallocate (pointer __p, size_type __n)
{
if (__p) {
assert (__buf == __p);
assert (__used_n == __n);
__used_n = 0;
}
}
};
MyAlloc::size_type MyAlloc::__used_n = 0;
char MyAlloc::__buf [512];
int main ()
{
char extbuf [3];
std::basic_stringbuf , MyAlloc> sbuf;
sbuf.pubsetbuf (extbuf, sizeof (extbuf));
// stdcxx extension used: basic_stringbuf::str (const char*, size_t)
sbuf.str ("abcdef", 6);
return 0;
}
--
The test output:
--
test: test.cpp:21: void MyAlloc::deallocate(char*, unsigned int): Assertion
`__buf == __p' failed.
Aborted
--
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-513) setjmp macro is not defined on Cygwin
[ https://issues.apache.org/jira/browse/STDCXX-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-513. -- Resolution: Fixed Fixed thus: http://svn.apache.org/viewvc?view=rev&rev=564170 > setjmp macro is not defined on Cygwin > - > > Key: STDCXX-513 > URL: https://issues.apache.org/jira/browse/STDCXX-513 > Project: C++ Standard Library > Issue Type: Bug > Components: 18. Language Support >Affects Versions: 4.1.3 > Environment: gcc 3.4.4/Cygwin >Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2 > > > setjmp macro is not defined in /usr/include/setjmp.h, so it should be defined > in include/ansi/csetjmp header file -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-513) setjmp macro is not defined on Cygwin
[ https://issues.apache.org/jira/browse/STDCXX-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov closed STDCXX-513. > setjmp macro is not defined on Cygwin > - > > Key: STDCXX-513 > URL: https://issues.apache.org/jira/browse/STDCXX-513 > Project: C++ Standard Library > Issue Type: Bug > Components: 18. Language Support >Affects Versions: 4.1.3 > Environment: gcc 3.4.4/Cygwin >Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2 > > > setjmp macro is not defined in /usr/include/setjmp.h, so it should be defined > in include/ansi/csetjmp header file -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-513) setjmp macro is not defined on Cygwin
setjmp macro is not defined on Cygwin - Key: STDCXX-513 URL: https://issues.apache.org/jira/browse/STDCXX-513 Project: C++ Standard Library Issue Type: Bug Components: 18. Language Support Affects Versions: 4.1.3 Environment: gcc 3.4.4/Cygwin Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.2 setjmp macro is not defined in /usr/include/setjmp.h, so it should be defined in include/ansi/csetjmp header 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-507) Access violation while loading libstdxxx.dll in dynamic builds on Cygwin
[ https://issues.apache.org/jira/browse/STDCXX-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517212 ] Farid Zaripov commented on STDCXX-507: -- There some problems with exporting basic_string, basic_string, exception::exception(), ... So switching to the 2). > Access violation while loading libstdxxx.dll in dynamic builds on Cygwin > > > 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 > Environment: gcc 3.4.4/Cygwin >Reporter: Farid Zaripov >Assignee: Farid Zaripov > Attachments: 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) Access violation while loading libstdxxx.dll in dynamic builds on Cygwin
[ https://issues.apache.org/jira/browse/STDCXX-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517164 ] Farid Zaripov commented on STDCXX-507: -- This is the old known issue of the cygwin ld auto-import feature: http://www.cygwin.com/ml/cygwin/2004-09/msg01101.html The possible solutions: 1) use __declspec (dllexport/dllimport) (disables auto-import feature) 2) use ld script (-Wl,--script,i386pe.x-no-rdata): http://qtwin.cvs.sourceforge.net/*checkout*/qtwin/qt-3/mkspecs/cygwin-g%2B%2B/i386pe.x-no-rdata?pathrev=QT_WIN32_3_3_BRANCH Now I try to check the 1). > Access violation while loading libstdxxx.dll in dynamic builds on Cygwin > > > 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 > Environment: gcc 3.4.4/Cygwin >Reporter: Farid Zaripov >Assignee: Farid Zaripov > Attachments: 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] Assigned: (STDCXX-507) Access violation while loading libstdxxx.dll in dynamic builds on Cygwin
[ https://issues.apache.org/jira/browse/STDCXX-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov reassigned STDCXX-507: Assignee: Farid Zaripov > Access violation while loading libstdxxx.dll in dynamic builds on Cygwin > > > 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 > Environment: gcc 3.4.4/Cygwin >Reporter: Farid Zaripov >Assignee: Farid Zaripov > Attachments: 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-508) __rw_catlist vector accessed beyond the last element in third call to catopen() (src/catalog.cpp)
[ https://issues.apache.org/jira/browse/STDCXX-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517039 ] Farid Zaripov commented on STDCXX-508: -- The issue will be closed after making the regression test. > __rw_catlist vector accessed beyond the last element in third call to > catopen() (src/catalog.cpp) > - > > Key: STDCXX-508 > URL: https://issues.apache.org/jira/browse/STDCXX-508 > Project: C++ Standard Library > Issue Type: Bug > Components: 22. Localization >Affects Versions: 4.1.2 > Environment: All >Reporter: Farid Zaripov >Assignee: Farid Zaripov > Fix For: 4.2 > > > std::vector<__rw_cat*> __rw_catlist initially created with size 2 > (catalog.cpp line 40). > During third call to catopen(), __rw_catlist vector accessed beyond the last > element. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-508) __rw_catlist vector accessed beyond the last element in third call to catopen() (src/catalog.cpp)
[ https://issues.apache.org/jira/browse/STDCXX-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-508. -- Resolution: Fixed Fixed thus: http://svn.apache.org/viewvc?view=rev&rev=555006 > __rw_catlist vector accessed beyond the last element in third call to > catopen() (src/catalog.cpp) > - > > Key: STDCXX-508 > URL: https://issues.apache.org/jira/browse/STDCXX-508 > Project: C++ Standard Library > Issue Type: Bug > Components: 22. Localization >Affects Versions: 4.1.2 > Environment: All >Reporter: Farid Zaripov >Assignee: Farid Zaripov > Fix For: 4.2 > > > std::vector<__rw_cat*> __rw_catlist initially created with size 2 > (catalog.cpp line 40). > During third call to catopen(), __rw_catlist vector accessed beyond the last > element. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-508) __rw_catlist vector accessed beyond the last element in third call to catopen() (src/catalog.cpp)
__rw_catlist vector accessed beyond the last element in third call to catopen() (src/catalog.cpp) - Key: STDCXX-508 URL: https://issues.apache.org/jira/browse/STDCXX-508 Project: C++ Standard Library Issue Type: Bug Components: 22. Localization Affects Versions: 4.1.2 Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Fix For: 4.2 std::vector<__rw_cat*> __rw_catlist initially created with size 2 (catalog.cpp line 40). During third call to catopen(), __rw_catlist vector accessed beyond the last element. -- 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-507) Access violation while loading libstdxxx.dll in dynamic builds on Cygwin
[ https://issues.apache.org/jira/browse/STDCXX-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516771 ] Farid Zaripov edited comment on STDCXX-507 at 7/31/07 11:58 AM: The attached file is the output of the dumpbin /IMPORTS localedef.exe was: The output of the dumpbin /IMPORTS localedef.exe > Access violation while loading libstdxxx.dll in dynamic builds on Cygwin > > > 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 > Environment: gcc 3.4.4/Cygwin >Reporter: Farid Zaripov > Attachments: 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) Access violation while loading libstdxxx.dll in dynamic builds on Cygwin
[ https://issues.apache.org/jira/browse/STDCXX-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-507: - Attachment: localedef.imports The output of the dumpbin /IMPORTS localedef.exe > Access violation while loading libstdxxx.dll in dynamic builds on Cygwin > > > 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 > Environment: gcc 3.4.4/Cygwin >Reporter: Farid Zaripov > Attachments: 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] Created: (STDCXX-507) Access violation while loading libstdxxx.dll in dynamic builds on Cygwin
Access violation while loading libstdxxx.dll in dynamic builds on Cygwin 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 Environment: gcc 3.4.4/Cygwin Reporter: Farid Zaripov 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] Closed: (STDCXX-466) basic_string<>::rfind() and basic_string<>::find_xxx() methods throws length_error(), but shouldn't
[ https://issues.apache.org/jira/browse/STDCXX-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov closed STDCXX-466. > basic_string<>::rfind() and basic_string<>::find_xxx() methods throws > length_error(), but shouldn't > --- > > Key: STDCXX-466 > URL: https://issues.apache.org/jira/browse/STDCXX-466 > Project: C++ Standard Library > Issue Type: Bug > Components: 21. Strings >Affects Versions: 4.2 > Environment: All >Reporter: Farid Zaripov >Assignee: Farid Zaripov > > The details are here: > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03795.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-466) basic_string<>::rfind() and basic_string<>::find_xxx() methods throws length_error(), but shouldn't
[ https://issues.apache.org/jira/browse/STDCXX-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-466. -- Resolution: Fixed Fixed thus: http://svn.apache.org/viewcvs?view=rev&rev=559037 > basic_string<>::rfind() and basic_string<>::find_xxx() methods throws > length_error(), but shouldn't > --- > > Key: STDCXX-466 > URL: https://issues.apache.org/jira/browse/STDCXX-466 > Project: C++ Standard Library > Issue Type: Bug > Components: 21. Strings >Affects Versions: 4.2 > Environment: All >Reporter: Farid Zaripov >Assignee: Farid Zaripov > > The details are here: > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03795.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-466) basic_string<>::rfind() and basic_string<>::find_xxx() methods throws length_error(), but shouldn't
[ https://issues.apache.org/jira/browse/STDCXX-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-466: - Summary: basic_string<>::rfind() and basic_string<>::find_xxx() methods throws length_error(), but shouldn't (was: basic_string<>::rfind() throws length_error(), but should return npos) > basic_string<>::rfind() and basic_string<>::find_xxx() methods throws > length_error(), but shouldn't > --- > > Key: STDCXX-466 > URL: https://issues.apache.org/jira/browse/STDCXX-466 > Project: C++ Standard Library > Issue Type: Bug > Components: 21. Strings >Affects Versions: 4.2 > Environment: All >Reporter: Farid Zaripov >Assignee: Farid Zaripov > > The details are here: > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03795.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (STDCXX-466) basic_string<>::rfind() throws length_error(), but should return npos
[ https://issues.apache.org/jira/browse/STDCXX-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov reopened STDCXX-466: -- > basic_string<>::rfind() throws length_error(), but should return npos > - > > Key: STDCXX-466 > URL: https://issues.apache.org/jira/browse/STDCXX-466 > Project: C++ Standard Library > Issue Type: Bug > Components: 21. Strings >Affects Versions: 4.2 > Environment: All >Reporter: Farid Zaripov >Assignee: Farid Zaripov > > The details are here: > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03795.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-175) std::string::replace (size_type, size_type, const_pointer, size_type) doesn't check last argument
[
https://issues.apache.org/jira/browse/STDCXX-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov closed STDCXX-175.
The regression test added thus: http://svn.apache.org/viewvc?view=rev&rev=559085
> std::string::replace (size_type, size_type, const_pointer, size_type) doesn't
> check last argument
> -
>
> Key: STDCXX-175
> URL: https://issues.apache.org/jira/browse/STDCXX-175
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 21. Strings
>Affects Versions: 4.1.3
> Environment: all
>Reporter: Anton Pevtsov
>Assignee: Farid Zaripov
>Priority: Minor
>
> The following test fails with segmentation fault:
> #include
> #include
> #include
> static char long_string [4096] = {'a'};
> int main (void)
> {
> try
> {
> std::string s (long_string, 4095);
> s.replace (0, 1, "a", s.max_size () + 1);
> std::cout << "Expect length error, got nothing" << '\n';
> }
> catch (std::length_error& e)
> {
> std::cout << "Got expected length error" << '\n';
> }
> return 0;
> }
> See the discussion for additional details:
> http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200604.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] Resolved: (STDCXX-175) std::string::replace (size_type, size_type, const_pointer, size_type) doesn't check last argument
[
https://issues.apache.org/jira/browse/STDCXX-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov resolved STDCXX-175.
--
Resolution: Fixed
Fixed thus: http://svn.apache.org/viewvc?view=rev&rev=559084
> std::string::replace (size_type, size_type, const_pointer, size_type) doesn't
> check last argument
> -
>
> Key: STDCXX-175
> URL: https://issues.apache.org/jira/browse/STDCXX-175
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 21. Strings
>Affects Versions: 4.1.3
> Environment: all
>Reporter: Anton Pevtsov
>Assignee: Farid Zaripov
>Priority: Minor
>
> The following test fails with segmentation fault:
> #include
> #include
> #include
> static char long_string [4096] = {'a'};
> int main (void)
> {
> try
> {
> std::string s (long_string, 4095);
> s.replace (0, 1, "a", s.max_size () + 1);
> std::cout << "Expect length error, got nothing" << '\n';
> }
> catch (std::length_error& e)
> {
> std::cout << "Got expected length error" << '\n';
> }
> return 0;
> }
> See the discussion for additional details:
> http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200604.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] Assigned: (STDCXX-175) std::string::replace (size_type, size_type, const_pointer, size_type) doesn't check last argument
[
https://issues.apache.org/jira/browse/STDCXX-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov reassigned STDCXX-175:
Assignee: Farid Zaripov
> std::string::replace (size_type, size_type, const_pointer, size_type) doesn't
> check last argument
> -
>
> Key: STDCXX-175
> URL: https://issues.apache.org/jira/browse/STDCXX-175
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 21. Strings
>Affects Versions: 4.1.3
> Environment: all
>Reporter: Anton Pevtsov
>Assignee: Farid Zaripov
>Priority: Minor
>
> The following test fails with segmentation fault:
> #include
> #include
> #include
> static char long_string [4096] = {'a'};
> int main (void)
> {
> try
> {
> std::string s (long_string, 4095);
> s.replace (0, 1, "a", s.max_size () + 1);
> std::cout << "Expect length error, got nothing" << '\n';
> }
> catch (std::length_error& e)
> {
> std::cout << "Got expected length error" << '\n';
> }
> return 0;
> }
> See the discussion for additional details:
> http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200604.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] Issue Comment Edited: (STDCXX-497) [MSVC 7.1] std::num_put bad formatting of 0.0 with precision and showpoint
[
https://issues.apache.org/jira/browse/STDCXX-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514978
]
Farid Zaripov edited comment on STDCXX-497 at 7/24/07 7:27 AM:
---
Already confirmed: https://issues.apache.org/jira/browse/STDCXX-2.
was:
Already confirmed (see https://issues.apache.org/jira/browse/STDCXX-2).
> [MSVC 7.1] std::num_put bad formatting of 0.0 with precision and showpoint
> --
>
> Key: STDCXX-497
> URL: https://issues.apache.org/jira/browse/STDCXX-497
> Project: C++ Standard Library
> Issue Type: Bug
>Affects Versions: 4.1.3
> Environment: MSVC 7.1
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
>
> Moved from Rogue Wave Bugzilla:
> http://bugzilla.cvo.roguewave.com/show_bug.cgi?id=1550
> $ cat t.cpp && cl -D_RWCONFIG=11s_msvc_7_1
> -Ic:/contrib/cygwin/build/sebor/dev-hal/include
> -I./../../../../include
> -Ic:/contrib/cygwin/build/sebor/dev-hal/examples/stdlib/manual/../include
> -Ic:/contrib/cygwin/build/sebor/dev-hal/include/ansi -I./../../../..
> -Ic:/contrib/cygwin/build/sebor/dev-hal
> -Ic:/contrib/cygwin/build/sebor/dev-hal/examples/stdlib/manual -I.
> -nologo -GX -MLd -W3 -Zi -GA -GR -GF -GZ -c t.cpp && link -nologo
> /NODEFAULTLIB:libcpd /debug /LIBPATH:./../../../../lib /OUT:t.exe
> t.obj std11s_msvc_7_1.lib user32.lib
> t.cpp && ./t.exe
> #include
> #include
> int main ()
> {
> std::ostringstream strm;
> strm.setf (strm.showpoint);
> strm.precision (2);
> strm << 0.0;
> assert ("0.0" == strm.str ());
> }
> Assertion failed: "0.0" == strm.str (), file t.cpp, line 13
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-497) [MSVC 7.1] std::num_put bad formatting of 0.0 with precision and showpoint
[
https://issues.apache.org/jira/browse/STDCXX-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514978
]
Farid Zaripov commented on STDCXX-497:
--
Already confirmed (see https://issues.apache.org/jira/browse/STDCXX-2).
> [MSVC 7.1] std::num_put bad formatting of 0.0 with precision and showpoint
> --
>
> Key: STDCXX-497
> URL: https://issues.apache.org/jira/browse/STDCXX-497
> Project: C++ Standard Library
> Issue Type: Bug
>Affects Versions: 4.1.3
> Environment: MSVC 7.1
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
>
> Moved from Rogue Wave Bugzilla:
> http://bugzilla.cvo.roguewave.com/show_bug.cgi?id=1550
> $ cat t.cpp && cl -D_RWCONFIG=11s_msvc_7_1
> -Ic:/contrib/cygwin/build/sebor/dev-hal/include
> -I./../../../../include
> -Ic:/contrib/cygwin/build/sebor/dev-hal/examples/stdlib/manual/../include
> -Ic:/contrib/cygwin/build/sebor/dev-hal/include/ansi -I./../../../..
> -Ic:/contrib/cygwin/build/sebor/dev-hal
> -Ic:/contrib/cygwin/build/sebor/dev-hal/examples/stdlib/manual -I.
> -nologo -GX -MLd -W3 -Zi -GA -GR -GF -GZ -c t.cpp && link -nologo
> /NODEFAULTLIB:libcpd /debug /LIBPATH:./../../../../lib /OUT:t.exe
> t.obj std11s_msvc_7_1.lib user32.lib
> t.cpp && ./t.exe
> #include
> #include
> int main ()
> {
> std::ostringstream strm;
> strm.setf (strm.showpoint);
> strm.precision (2);
> strm << 0.0;
> assert ("0.0" == strm.str ());
> }
> Assertion failed: "0.0" == strm.str (), file t.cpp, line 13
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-466) basic_string<>::rfind() throws length_error(), but should return npos
[ https://issues.apache.org/jira/browse/STDCXX-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov closed STDCXX-466. Regression test added thus: http://svn.apache.org/viewvc?view=rev&rev=558688 > basic_string<>::rfind() throws length_error(), but should return npos > - > > Key: STDCXX-466 > URL: https://issues.apache.org/jira/browse/STDCXX-466 > Project: C++ Standard Library > Issue Type: Bug > Components: 21. Strings >Affects Versions: 4.2 > Environment: All >Reporter: Farid Zaripov >Assignee: Farid Zaripov > > The details are here: > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03795.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-466) basic_string<>::rfind() throws length_error(), but should return npos
[ https://issues.apache.org/jira/browse/STDCXX-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-466. -- Resolution: Fixed Fixed thus: http://svn.apache.org/viewvc?view=rev&rev=557742 > basic_string<>::rfind() throws length_error(), but should return npos > - > > Key: STDCXX-466 > URL: https://issues.apache.org/jira/browse/STDCXX-466 > Project: C++ Standard Library > Issue Type: Bug > Components: 21. Strings >Affects Versions: 4.2 > Environment: All >Reporter: Farid Zaripov >Assignee: Farid Zaripov > > The details are here: > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03795.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
