stdcxx-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek (JIRA)" <j...@apache.org>
Subject [jira] Commented: (STDCXX-846) [XLC++ 7,8,9] ABRT in 22.locale.num.get.mt
Date Fri, 18 Apr 2008 17:40:21 GMT

    [ 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.


Mime
View raw message