[
https://issues.apache.org/jira/browse/STDCXX-846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590535#action_12590535
]
Travis Vitek commented on STDCXX-846:
-------------------------------------
But are there countries with no grouping? Is it valid to set the thousands
seperator to the empty string to indicate that there is no grouping in a C
locale? It sure seems that it is according to 7.11.2.1 p3 of C99. It reads.
.
{noformat}
The members of the structure with type char * are pointers to strings, any of
which
(except decimal_point) can point to "", to indicate that the value is not
available in
the current locale or is of zero length. Apart from grouping and mon_grouping,
the
{noformat}
I believe that this says quite clearly that if the {{thousands_sep}} field is
the empty string, then the thousands seperator is not available or is of zero
length. The only way to express this in the C++ locale is to ignore the
grouping that is specified and act as if the grouping is set to the empty
string also. Unfortunately this can result in the loss of some information [if
the user queries the C++ grouping they will get a different result wrt the C
grouping], but I think that this is a limitation of the design of the C++
locale facilities and isn't likely to change.
I understand that in an ideal world the locales would have both
{{thousands_sep}} and {{grouping}} set to the empty string [like what is
requird of the C/POSIX locale in C], but it doesn't appear that the C standard
requires it, and the locale utilities don't seem to require it either.
> [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
> Time Spent: 4h
> Remaining Estimate: 0h
>
> 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.
