You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@stdcxx.apache.org by "Travis Vitek (JIRA)" <ji...@apache.org> on 2008/03/03 20:48:50 UTC
[jira] Created: (STDCXX-742) [IBM XLC++ 9.0/AIX 5.3]
22.locale.messages fails with assertions
[IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
----------------------------------------------------------------
Key: STDCXX-742
URL: https://issues.apache.org/jira/browse/STDCXX-742
Project: C++ Standard Library
Issue Type: Bug
Components: 22. Localization
Affects Versions: 4.2.1
Reporter: Travis Vitek
Assignee: Travis Vitek
Priority: Minor
Fix For: 4.2.1
This is an additional set of failures that remain after fixing the catopen() failure in STDCXX-665.
{noformat}
# ASSERTION (S7) (4 lines):
# TEXT: has_fact<messages_byname<char> >(locale()) == false
# CLAUSE: lib.category.messages
# LINE: 320
# ASSERTION (S7) (4 lines):
# TEXT: use_fact<messages_byname<char> >(locale()) failed to throw
# CLAUSE: lib.category.messages
# LINE: 329
# ASSERTION (S7) (4 lines):
# TEXT: has_fact<messages_byname<char> >(locale("C")) == true
# CLAUSE: lib.category.messages
# LINE: 320
# ASSERTION (S7) (4 lines):
# TEXT: use_fact<messages_byname<char> >(locale("C")) failed to throw
# CLAUSE: lib.category.messages
# LINE: 329
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-742) [IBM XLC++ 9.0/AIX 5.3]
22.locale.messages fails with assertions
Posted by "Travis Vitek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Travis Vitek closed STDCXX-742.
-------------------------------
Closing resolved and verified 4.2.1 issue.
> [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
> ----------------------------------------------------------------
>
> Key: STDCXX-742
> URL: https://issues.apache.org/jira/browse/STDCXX-742
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
> Affects Versions: 4.2.0
> Reporter: Travis Vitek
> Assignee: Travis Vitek
> Priority: Minor
> Fix For: 4.2.1
>
> Original Estimate: 3h
> Time Spent: 3h
> Remaining Estimate: 0h
>
> This is an additional set of failures that remain after fixing the catopen() failure in STDCXX-665.
> {noformat}
> # ASSERTION (S7) (4 lines):
> # TEXT: has_fact<messages_byname<char> >(locale()) == false
> # CLAUSE: lib.category.messages
> # LINE: 320
> # ASSERTION (S7) (4 lines):
> # TEXT: use_fact<messages_byname<char> >(locale()) failed to throw
> # CLAUSE: lib.category.messages
> # LINE: 329
> # ASSERTION (S7) (4 lines):
> # TEXT: has_fact<messages_byname<char> >(locale("C")) == true
> # CLAUSE: lib.category.messages
> # LINE: 320
> # ASSERTION (S7) (4 lines):
> # TEXT: use_fact<messages_byname<char> >(locale("C")) failed to throw
> # CLAUSE: lib.category.messages
> # LINE: 329
> {noformat}
--
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-742) [IBM XLC++ 9.0/AIX 5.3]
22.locale.messages fails with assertions
Posted by "Travis Vitek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584278#action_12584278 ]
vitek edited comment on STDCXX-742 at 4/1/08 1:06 PM:
-------------------------------------------------------------
This is happening because we don't use the -qrtti=dynamiccast option. We internally use a dynamic_cast to determine if the facet is of the correct derived type, but if dynamic_cast isn't supported we use a C style cast, and that returns bad results.
This case is essentially the same as STDCXX-664. We didn't add -qrtti=dynamiccast back then, and we just worked around the issue in the test. It seems to me that we should have added the flag. Would this be a binary compatible change?
was (Author: vitek):
This is happening because we don't use the -qrtti=dynamiccast option. We internally use a dynamic_cast to determine if the facet is of the correct derived type, but if dynamic_cast isn't supported we use a C style cast, and that returns bad results.
This case is essentially the same as STDCXX-644. We didn't add -qrtti=dynamiccast back then, and we just worked around the issue in the test. It seems to me that we should have added the flag. Would this be a binary compatible change?
> [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
> ----------------------------------------------------------------
>
> Key: STDCXX-742
> URL: https://issues.apache.org/jira/browse/STDCXX-742
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
> Affects Versions: 4.2.1
> Reporter: Travis Vitek
> Assignee: Travis Vitek
> Priority: Minor
> Fix For: 4.2.1
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> This is an additional set of failures that remain after fixing the catopen() failure in STDCXX-665.
> {noformat}
> # ASSERTION (S7) (4 lines):
> # TEXT: has_fact<messages_byname<char> >(locale()) == false
> # CLAUSE: lib.category.messages
> # LINE: 320
> # ASSERTION (S7) (4 lines):
> # TEXT: use_fact<messages_byname<char> >(locale()) failed to throw
> # CLAUSE: lib.category.messages
> # LINE: 329
> # ASSERTION (S7) (4 lines):
> # TEXT: has_fact<messages_byname<char> >(locale("C")) == true
> # CLAUSE: lib.category.messages
> # LINE: 320
> # ASSERTION (S7) (4 lines):
> # TEXT: use_fact<messages_byname<char> >(locale("C")) failed to throw
> # CLAUSE: lib.category.messages
> # LINE: 329
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-742) [IBM XLC++ 9.0/AIX 5.3]
22.locale.messages fails with assertions
Posted by "Travis Vitek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Travis Vitek updated STDCXX-742:
--------------------------------
Remaining Estimate: 3h (was: 0.05h)
Original Estimate: 3h (was: 0.05h)
Update estimate to something a little more realistic.
> [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
> ----------------------------------------------------------------
>
> Key: STDCXX-742
> URL: https://issues.apache.org/jira/browse/STDCXX-742
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
> Affects Versions: 4.2.1
> Reporter: Travis Vitek
> Assignee: Travis Vitek
> Priority: Minor
> Fix For: 4.2.1
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> This is an additional set of failures that remain after fixing the catopen() failure in STDCXX-665.
> {noformat}
> # ASSERTION (S7) (4 lines):
> # TEXT: has_fact<messages_byname<char> >(locale()) == false
> # CLAUSE: lib.category.messages
> # LINE: 320
> # ASSERTION (S7) (4 lines):
> # TEXT: use_fact<messages_byname<char> >(locale()) failed to throw
> # CLAUSE: lib.category.messages
> # LINE: 329
> # ASSERTION (S7) (4 lines):
> # TEXT: has_fact<messages_byname<char> >(locale("C")) == true
> # CLAUSE: lib.category.messages
> # LINE: 320
> # ASSERTION (S7) (4 lines):
> # TEXT: use_fact<messages_byname<char> >(locale("C")) failed to throw
> # CLAUSE: lib.category.messages
> # LINE: 329
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (STDCXX-742) [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages
fails with assertions
Posted by Martin Sebor <se...@roguewave.com>.
Travis Vitek wrote:
>
>
>> Martin Sebor wrote:
>>
>> Travis Vitek wrote:
>>>
>>>
>>>> Travis Vitek commented on STDCXX-742:
>>>> -------------------------------------
>>>>
>>>> This is happening because we don't use the -qrtti=dynamiccast
>>>> option. We internally use a dynamic_cast to determine if the
>>>> facet is of the correct derived type, but if dynamic_cast
>>>> isn't supported we use a C style cast, and that returns bad results.
>>>>
>>>> This case is essentially the same as STDCXX-664. We didn't add
>>>> -qrtti=dynamiccast back then, and we just worked around the
>>>> issue in the test. It seems to me that we should have added
>>>> the flag. Would this be a binary compatible change?
>>>>
>>> What are the thoughts on this? There was some discussion
>>> [http://tinyurl.com/3xfdma] of enabling -qrtti=dynamiccast for the
>>> VisualAge C++ compiler, but it petered out.
>> Is there any way to turn on rtti using a pragma? That way we could
>> enable it only for translation units that included <locale> and we
>> wouldn't be shoving the option down the throats of users who don't
>> care about named locales.
>
> No, there is no pragma for this. Even if there were we would need to do
> some hacking to get it to work. We try determine if dynamic_cast<>()
> exists and is functioning correctly at configuration time. If that
> config test fails, we define _RWSTD_NO_DYNAMIC_CAST. So even if we
> managed to enable rtti when <locale> was included, we would need to
> 'fix' the _RWSTD_NO_DYNAMIC_CAST and _RWSTD_DYNAMIC_CAST macros. Ewww..
Or just add a special implementation just for XLC++. But sounds
like that's not possible anyway.
>
>> Btw., does XLC++ itself correctly handle the test case mentioned
>> in the thread, even without -qrtti? (It's possible to get some
>> simple cases to work even w/o the option but not all of them).
>>
>
> I'm not absolutely sure what you're asking. It sounds like you are
> asking if the Standard C++ Library implementation that ships with XLC++
> has this same problem.
That's exactly what I was asking, thanks.
> The answer to that is no...
I wonder if it would get this right:
struct MyMessages: std::messages<char> { };
assert (!std::has_facet<MyMessages>(std::locale::classic ()));
If not, they probably have their own simple version of "RTTI" built
into the facet (e.g., via a virtual function) but they still can't
handle tricky cases like this one. Unfortunately, we can't even do
this much w/o breaking binary compatibility.
All in all, I'm still not sure this fairly obscure corner case is
worth the effort of adding a compiler option for. C++ locales are
used by only a small community of users, and I suspect that this
case (calling has_facet or use_facet with a facet derived from one
of the standard ones) is unlikely to come up even in their "advanced"
uses. I say we open an issue for this just for the record and keep
deferring it until we feel like adding the option or until IBM
decides to enable RTTI by default.
Martin
>
> $ type t.cpp
> #include <locale>
> #include <cstring>
> #include <cassert>
>
> template <class charT>
> void test_has_facet (const char *loc_name, const char *cname)
> {
> const std::locale loc =
> loc_name ? std::locale (loc_name) : std::locale ();
>
> typedef std::messages_byname<charT> ByName;
>
> const bool byname = loc_name
> && std::strcmp (loc_name, "C");
>
> const bool facet_exists = std::has_facet<ByName>(loc);
>
> assert (byname == facet_exists);
>
> try {
> // verify that use facet throws an exception only
> // for the default and "C" locales
> std::use_facet<ByName>(loc);
>
> assert (byname);
> }
> catch (std::exception &ex) {
> assert (!byname);
> }
> }
>
> template <class charT>
> void test_messages (charT, const char *cname)
> {
> // exercise has_facet and use_facet in the default locale
> test_has_facet<charT>(0, cname);
>
> // exercise has_facet and use_facet in locale("C")
> test_has_facet<charT>("C", cname);
> }
>
> int main (int, char*[])
> {
> test_messages (char (), "char");
>
> return 0;
> }
>
> $ xlC t.cpp -o t && ./t
> $
>
> If I run the same code under stdcxx, I get the following
>
> $ gmake t && ./t
>
> <snip>
>
> Assertion failed: byname == facet_exists, file t.cpp, line 18
> IOT/Abort trap (core dumped)
> $
>
> Travis
>
RE: [jira] Commented: (STDCXX-742) [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
Posted by Travis Vitek <Tr...@roguewave.com>.
>Martin Sebor wrote:
>
>Travis Vitek wrote:
>>
>>
>>> Travis Vitek commented on STDCXX-742:
>>> -------------------------------------
>>>
>>> This is happening because we don't use the -qrtti=dynamiccast
>>> option. We internally use a dynamic_cast to determine if the
>>> facet is of the correct derived type, but if dynamic_cast
>>> isn't supported we use a C style cast, and that returns bad results.
>>>
>>> This case is essentially the same as STDCXX-664. We didn't add
>>> -qrtti=dynamiccast back then, and we just worked around the
>>> issue in the test. It seems to me that we should have added
>>> the flag. Would this be a binary compatible change?
>>>
>>
>> What are the thoughts on this? There was some discussion
>> [http://tinyurl.com/3xfdma] of enabling -qrtti=dynamiccast for the
>> VisualAge C++ compiler, but it petered out.
>
>Is there any way to turn on rtti using a pragma? That way we could
>enable it only for translation units that included <locale> and we
>wouldn't be shoving the option down the throats of users who don't
>care about named locales.
No, there is no pragma for this. Even if there were we would need to do
some hacking to get it to work. We try determine if dynamic_cast<>()
exists and is functioning correctly at configuration time. If that
config test fails, we define _RWSTD_NO_DYNAMIC_CAST. So even if we
managed to enable rtti when <locale> was included, we would need to
'fix' the _RWSTD_NO_DYNAMIC_CAST and _RWSTD_DYNAMIC_CAST macros. Ewww..
>
>Btw., does XLC++ itself correctly handle the test case mentioned
>in the thread, even without -qrtti? (It's possible to get some
>simple cases to work even w/o the option but not all of them).
>
I'm not absolutely sure what you're asking. It sounds like you are
asking if the Standard C++ Library implementation that ships with XLC++
has this same problem. The answer to that is no...
$ type t.cpp
#include <locale>
#include <cstring>
#include <cassert>
template <class charT>
void test_has_facet (const char *loc_name, const char *cname)
{
const std::locale loc =
loc_name ? std::locale (loc_name) : std::locale ();
typedef std::messages_byname<charT> ByName;
const bool byname = loc_name
&& std::strcmp (loc_name, "C");
const bool facet_exists = std::has_facet<ByName>(loc);
assert (byname == facet_exists);
try {
// verify that use facet throws an exception only
// for the default and "C" locales
std::use_facet<ByName>(loc);
assert (byname);
}
catch (std::exception &ex) {
assert (!byname);
}
}
template <class charT>
void test_messages (charT, const char *cname)
{
// exercise has_facet and use_facet in the default locale
test_has_facet<charT>(0, cname);
// exercise has_facet and use_facet in locale("C")
test_has_facet<charT>("C", cname);
}
int main (int, char*[])
{
test_messages (char (), "char");
return 0;
}
$ xlC t.cpp -o t && ./t
$
If I run the same code under stdcxx, I get the following
$ gmake t && ./t
<snip>
Assertion failed: byname == facet_exists, file t.cpp, line 18
IOT/Abort trap (core dumped)
$
Travis
Re: [jira] Commented: (STDCXX-742) [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages
fails with assertions
Posted by Martin Sebor <se...@roguewave.com>.
Travis Vitek wrote:
>
>
>> Travis Vitek commented on STDCXX-742:
>> -------------------------------------
>>
>> This is happening because we don't use the -qrtti=dynamiccast
>> option. We internally use a dynamic_cast to determine if the
>> facet is of the correct derived type, but if dynamic_cast
>> isn't supported we use a C style cast, and that returns bad results.
>>
>> This case is essentially the same as STDCXX-664. We didn't add
>> -qrtti=dynamiccast back then, and we just worked around the
>> issue in the test. It seems to me that we should have added
>> the flag. Would this be a binary compatible change?
>>
>
> What are the thoughts on this? There was some discussion
> [http://tinyurl.com/3xfdma] of enabling -qrtti=dynamiccast for the
> VisualAge C++ compiler, but it petered out.
Is there any way to turn on rtti using a pragma? That way we could
enable it only for translation units that included <locale> and we
wouldn't be shoving the option down the throats of users who don't
care about named locales.
Btw., does XLC++ itself correctly handle the test case mentioned
in the thread, even without -qrtti? (It's possible to get some
simple cases to work even w/o the option but not all of them).
Martin
RE: [jira] Commented: (STDCXX-742) [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
Posted by Travis Vitek <Tr...@roguewave.com>.
>Travis Vitek commented on STDCXX-742:
>-------------------------------------
>
>This is happening because we don't use the -qrtti=dynamiccast
>option. We internally use a dynamic_cast to determine if the
>facet is of the correct derived type, but if dynamic_cast
>isn't supported we use a C style cast, and that returns bad results.
>
>This case is essentially the same as STDCXX-664. We didn't add
>-qrtti=dynamiccast back then, and we just worked around the
>issue in the test. It seems to me that we should have added
>the flag. Would this be a binary compatible change?
>
What are the thoughts on this? There was some discussion
[http://tinyurl.com/3xfdma] of enabling -qrtti=dynamiccast for the
VisualAge C++ compiler, but it petered out.
Travis
[jira] Commented: (STDCXX-742) [IBM XLC++ 9.0/AIX 5.3]
22.locale.messages fails with assertions
Posted by "Travis Vitek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584278#action_12584278 ]
Travis Vitek commented on STDCXX-742:
-------------------------------------
This is happening because we don't use the -qrtti=dynamiccast option. We internally use a dynamic_cast to determine if the facet is of the correct derived type, but if dynamic_cast isn't supported we use a C style cast, and that returns bad results.
This case is essentially the same as STDCXX-644. We didn't add -qrtti=dynamiccast back then, and we just worked around the issue in the test. It seems to me that we should have added the flag. Would this be a binary compatible change?
> [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
> ----------------------------------------------------------------
>
> Key: STDCXX-742
> URL: https://issues.apache.org/jira/browse/STDCXX-742
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
> Affects Versions: 4.2.1
> Reporter: Travis Vitek
> Assignee: Travis Vitek
> Priority: Minor
> Fix For: 4.2.1
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> This is an additional set of failures that remain after fixing the catopen() failure in STDCXX-665.
> {noformat}
> # ASSERTION (S7) (4 lines):
> # TEXT: has_fact<messages_byname<char> >(locale()) == false
> # CLAUSE: lib.category.messages
> # LINE: 320
> # ASSERTION (S7) (4 lines):
> # TEXT: use_fact<messages_byname<char> >(locale()) failed to throw
> # CLAUSE: lib.category.messages
> # LINE: 329
> # ASSERTION (S7) (4 lines):
> # TEXT: has_fact<messages_byname<char> >(locale("C")) == true
> # CLAUSE: lib.category.messages
> # LINE: 320
> # ASSERTION (S7) (4 lines):
> # TEXT: use_fact<messages_byname<char> >(locale("C")) failed to throw
> # CLAUSE: lib.category.messages
> # LINE: 329
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-742) [IBM XLC++ 9.0/AIX 5.3]
22.locale.messages fails with assertions
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Sebor updated STDCXX-742:
--------------------------------
Affects Version/s: (was: 4.2.1)
4.2.0
The same assertions (and more) also fail in 4.2.0. Set Affects Version/s accordingly.
> [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
> ----------------------------------------------------------------
>
> Key: STDCXX-742
> URL: https://issues.apache.org/jira/browse/STDCXX-742
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
> Affects Versions: 4.2.0
> Reporter: Travis Vitek
> Assignee: Travis Vitek
> Priority: Minor
> Fix For: 4.2.1
>
> Original Estimate: 3h
> Time Spent: 3h
> Remaining Estimate: 0h
>
> This is an additional set of failures that remain after fixing the catopen() failure in STDCXX-665.
> {noformat}
> # ASSERTION (S7) (4 lines):
> # TEXT: has_fact<messages_byname<char> >(locale()) == false
> # CLAUSE: lib.category.messages
> # LINE: 320
> # ASSERTION (S7) (4 lines):
> # TEXT: use_fact<messages_byname<char> >(locale()) failed to throw
> # CLAUSE: lib.category.messages
> # LINE: 329
> # ASSERTION (S7) (4 lines):
> # TEXT: has_fact<messages_byname<char> >(locale("C")) == true
> # CLAUSE: lib.category.messages
> # LINE: 320
> # ASSERTION (S7) (4 lines):
> # TEXT: use_fact<messages_byname<char> >(locale("C")) failed to throw
> # CLAUSE: lib.category.messages
> # LINE: 329
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-742) [IBM XLC++ 9.0/AIX 5.3]
22.locale.messages fails with assertions
Posted by "Farid Zaripov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12589942#action_12589942 ]
Farid Zaripov commented on STDCXX-742:
--------------------------------------
Merged in 4.2.x branch thus: http://svn.apache.org/viewvc?view=rev&revision=648752
> [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
> ----------------------------------------------------------------
>
> Key: STDCXX-742
> URL: https://issues.apache.org/jira/browse/STDCXX-742
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
> Affects Versions: 4.2.1
> Reporter: Travis Vitek
> Assignee: Travis Vitek
> Priority: Minor
> Fix For: 4.2.1
>
> Original Estimate: 3h
> Time Spent: 3h
> Remaining Estimate: 0h
>
> This is an additional set of failures that remain after fixing the catopen() failure in STDCXX-665.
> {noformat}
> # ASSERTION (S7) (4 lines):
> # TEXT: has_fact<messages_byname<char> >(locale()) == false
> # CLAUSE: lib.category.messages
> # LINE: 320
> # ASSERTION (S7) (4 lines):
> # TEXT: use_fact<messages_byname<char> >(locale()) failed to throw
> # CLAUSE: lib.category.messages
> # LINE: 329
> # ASSERTION (S7) (4 lines):
> # TEXT: has_fact<messages_byname<char> >(locale("C")) == true
> # CLAUSE: lib.category.messages
> # LINE: 320
> # ASSERTION (S7) (4 lines):
> # TEXT: use_fact<messages_byname<char> >(locale("C")) failed to throw
> # CLAUSE: lib.category.messages
> # LINE: 329
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-742) [IBM XLC++ 9.0/AIX 5.3]
22.locale.messages fails with assertions
Posted by "Travis Vitek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584315#action_12584315 ]
Travis Vitek commented on STDCXX-742:
-------------------------------------
Committed to trunk in [r643573|http://svn.apache.org/viewvc?view=rev&revision=643573]. Needs to be merged to 4.2.1 before closing.
> [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
> ----------------------------------------------------------------
>
> Key: STDCXX-742
> URL: https://issues.apache.org/jira/browse/STDCXX-742
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
> Affects Versions: 4.2.1
> Reporter: Travis Vitek
> Assignee: Travis Vitek
> Priority: Minor
> Fix For: 4.2.1
>
> Original Estimate: 3h
> Time Spent: 2h
> Remaining Estimate: 1h
>
> This is an additional set of failures that remain after fixing the catopen() failure in STDCXX-665.
> {noformat}
> # ASSERTION (S7) (4 lines):
> # TEXT: has_fact<messages_byname<char> >(locale()) == false
> # CLAUSE: lib.category.messages
> # LINE: 320
> # ASSERTION (S7) (4 lines):
> # TEXT: use_fact<messages_byname<char> >(locale()) failed to throw
> # CLAUSE: lib.category.messages
> # LINE: 329
> # ASSERTION (S7) (4 lines):
> # TEXT: has_fact<messages_byname<char> >(locale("C")) == true
> # CLAUSE: lib.category.messages
> # LINE: 320
> # ASSERTION (S7) (4 lines):
> # TEXT: use_fact<messages_byname<char> >(locale("C")) failed to throw
> # CLAUSE: lib.category.messages
> # LINE: 329
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-742) [IBM XLC++ 9.0/AIX 5.3]
22.locale.messages fails with assertions
Posted by "Travis Vitek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Travis Vitek resolved STDCXX-742.
---------------------------------
Resolution: Fixed
> [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
> ----------------------------------------------------------------
>
> Key: STDCXX-742
> URL: https://issues.apache.org/jira/browse/STDCXX-742
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
> Affects Versions: 4.2.1
> Reporter: Travis Vitek
> Assignee: Travis Vitek
> Priority: Minor
> Fix For: 4.2.1
>
> Original Estimate: 3h
> Time Spent: 2h
> Remaining Estimate: 1h
>
> This is an additional set of failures that remain after fixing the catopen() failure in STDCXX-665.
> {noformat}
> # ASSERTION (S7) (4 lines):
> # TEXT: has_fact<messages_byname<char> >(locale()) == false
> # CLAUSE: lib.category.messages
> # LINE: 320
> # ASSERTION (S7) (4 lines):
> # TEXT: use_fact<messages_byname<char> >(locale()) failed to throw
> # CLAUSE: lib.category.messages
> # LINE: 329
> # ASSERTION (S7) (4 lines):
> # TEXT: has_fact<messages_byname<char> >(locale("C")) == true
> # CLAUSE: lib.category.messages
> # LINE: 320
> # ASSERTION (S7) (4 lines):
> # TEXT: use_fact<messages_byname<char> >(locale("C")) failed to throw
> # CLAUSE: lib.category.messages
> # LINE: 329
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.