[
https://issues.apache.org/jira/browse/STDCXX-846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590327#action_12590327
]
Travis Vitek commented on STDCXX-846:
-------------------------------------
I know that C++ locales have problems with null thousands seperators so I'm not
exactly sure what we should do about this. Perhaps the test should be updated
to enumerate locales with {{rw_locale_query()}} or to terminate the stream with
eof which is correctly handled.. Unfortunately that doesn't really help the
users.
I'm wondering if we should detect the null thousands seperator, and if we see
it we could clear the grouping. It doesn't seem like it would be that
difficult, it looks like a one line change to {{__rw_get_numpunct()}}, but I'm
not sure if it is correct or even a good idea. Anyone?
{noformat}
Index: punct.cpp
===================================================================
--- punct.cpp (revision 648282)
+++ punct.cpp (working copy)
@@ -148,9 +148,9 @@
// be prepared to handle (non-conforming) null pointers
// (e.g., AIX -- see bug #558)
- const char* const grp = pconv->grouping ? pconv->grouping : "";
const char* const dp = pconv->decimal_point ? pconv->decimal_point : "";
const char* const ts = pconv->thousands_sep ? pconv->thousands_sep : "";
+ const char* const grp = *ts && pconv->grouping ? pconv->grouping : "";
// the size of the narrow grouping string in bytes
const size_t grsz = strlen (grp) + 1;
{noformat}
> [XLC++ 7,8,9] ABRT in 22.locale.num.get.mt
> ------------------------------------------
>
> Key: STDCXX-846
> URL: https://issues.apache.org/jira/browse/STDCXX-846
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Tests
> Affects Versions: 4.2.1
> Environment: AIX 5.3 PowerPC IBM XLC++ 9.0
> AIX 5.3 PowerPC IBM XLC++ 8.0
> AIX 5.3 PowerPC IBM XLC++ 7.0
> Reporter: Travis Vitek
> Assignee: Travis Vitek
> Fix For: 4.2.1
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> On AIX, when compiled with XLC++, the test
> [22.locale.num.get.mt.cpp|http://svn.apache.org/viewvc/stdcxx/trunk/tests/localization/22.locale.num.get.mt.cpp?view=markup]
> fails with a {{SIGABRT}}. This failure is not likely to be an indication of
> a thread safety problem because it happens consistently for non-reentrant
> builds.
> This is a new test for 4.2.1, so it is considered a regression.
> {noformat}
> $ 22.locale.num.get.mt
> # INFO (S1) (10 lines):
> # TEXT:
> # COMPILER: IBM VisualAge C++, __IBMCPP__ = 900
> # ENVIRONMENT: powerpc/LP64 running aix-5.3
> # FILE: 22.locale.num.get.mt.cpp
> # COMPILED: Apr 9 2008, 16:38:10
> # COMMENT: thread safety
> ############################################################
> # CLAUSE: lib.locale.num.get
> # NOTE (S2) (5 lines):
> # TEXT: executing "locale -a > /tmp/tmpfile-w1Upya"
> # CLAUSE: lib.locale.num.get
> # FILE: process.cpp
> # LINE: 279
> # INFO (S1) (3 lines):
> # TEXT: testing std::num_get<charT> with 8 threads, 100000 iterations each,
> in 32 locales \
> { "C" "POSIX" "AR_DZ.UTF-8" "AR_BH" "AR_AA.UTF-8" "AR_BH.UTF-8"
> "AR_AE.UTF-8" \
> "AR_DZ" "AR_EG.UTF-8" "AR_EG" "AR_AE" "AR_AA" "AR_JO" "AR_JO.UTF-8"
> "AR_KW" \
> "AR_KW.UTF-8" "AR_LB" "AR_LB.UTF-8" "AR_MA" "AR_MA.UTF-8" "AR_OM"
> "AR_OM.UTF-8" \
> "AR_QA" "AR_QA.UTF-8" "AR_SA" "AR_SA.UTF-8" "AR_SY" "AR_SY.UTF-8" "AR_TN"
> \
> "AR_TN.UTF-8" "AR_YE" "AR_YE.UTF-8" }
> # CLAUSE: lib.locale.num.get
> # INFO (S1) (3 lines):
> # TEXT: exercising std::num_get<char>
> # CLAUSE: lib.locale.num.get
> /amd/devco/vitek/stdcxx/trunk/tests/localization/22.locale.num.get.mt.cpp:245:
> \
> test_get_data<char,std::char_traits<char> >: Assertion '! (state &
> std::ios_base::failbit)' failed.
> IOT/Abort trap (core dumped)
> $ dbx 22.locale.num.get.mt
> Type 'help' for help.
> [using memory image in core]
> reading symbolic information ...
> IOT/Abort trap in pthread_kill at 0x90000006ce3a5bc ($t2)
> 0x90000006ce3a5bc (pthread_kill+0x88) e8410028 ld r2,0x28(r1)
> (dbx) where
> pthread_kill(??, ??) at 0x90000006ce3a5bc
> _p_raise(??) at 0x90000006ce39ff8
> raise.raise(??) at 0x90000000005893c
> abort() at 0x900000000083c0c
> __rw_assert_fail__4__rwFPCcT1iT1() at 0x10008b45c
> unnamed block in 22.locale.num.get.mt.void
> test_get_data<char,std::char_traits<char> >( \
> const MyNumData&,\
> const
> std::num_get<char,std::istreambuf_iterator<char,std::char_traits<char> > >&, \
> const std::istreambuf_iterator<char,std::char_traits<char> >&,\
> const std::istreambuf_iterator<char,std::char_traits<char> >&, \
> std::basic_ios<char,std::char_traits<char> >&)\
> (data = &(...), np = &(...), iter = &(...), end = &(...), io = &(...)),
> line 245 in "22.locale.num.get.mt.cpp"
> 22.locale.num.get.mt.void test_get_data<char,std::char_traits<char> >( \
> const MyNumData&, \
> const
> std::num_get<char,std::istreambuf_iterator<char,std::char_traits<char> > >&, \
> const std::istreambuf_iterator<char,std::char_traits<char> >&, \
> const std::istreambuf_iterator<char,std::char_traits<char> >&, \
> std::basic_ios<char,std::char_traits<char> >&)
> (data = &(...), np = &(...), iter = &(...), end = &(...), io = &(...)),
> line 245 in "22.locale.num.get.mt.cpp"
> unnamed block in thread_func(void*)( = 0x0fffffffffffef50), line 349 in
> "22.locale.num.get.mt.cpp"
> unnamed block in thread_func(void*)( = 0x0fffffffffffef50), line 349 in
> "22.locale.num.get.mt.cpp"
> thread_func(void*)( = 0x0fffffffffffef50), line 349 in
> "22.locale.num.get.mt.cpp"
> (dbx) quit
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
