stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Sebor (JIRA)" <j...@apache.org>
Subject [jira] Commented: (STDCXX-277) Locale stage 2 test failure
Date Tue, 29 Aug 2006 00:46:29 GMT
    [ http://issues.apache.org/jira/browse/STDCXX-277?page=comments#action_12431106 ] 
            
Martin Sebor commented on STDCXX-277:
-------------------------------------

I think the source of the problem is that the locale utility prints out the collating weights
as characters in the decimal notation regardless of their value and localedef rejects them
based on the POSIX requirement that each character in decimal notation represent a byte value.
Quoting from http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html#tag_07_03:

    A character can be represented as a decimal constant. A decimal constant shall be specified
as the escape character
    followed by a 'd' followed by two or three decimal digits. Each constant represents a
byte value. Multi-byte values can be
    represented by concatenated constants specified in byte order with the last constant specifying
the least significant byte
    of the character.

So weights greater than UCHAR_MAX should probably be formatted as multibyte characters instead.
For example, 383 should be formatted as "\d01;\d127" and not as "\d383".

> Locale stage 2 test failure
> ---------------------------
>
>                 Key: STDCXX-277
>                 URL: http://issues.apache.org/jira/browse/STDCXX-277
>             Project: C++ Standard Library
>          Issue Type: Bug
>          Components: Utilities
>         Environment: Multiple, including Linux 2.6.14.5 + gcc 3.2.3
>            Reporter: Andrew Black
>         Attachments: en_US.ISO-8859-1.sh.out, out.1
>
>
> To test the locales, the run_locale_utils.sh script is used, residing in the etc/config
subdirectory of the source directory.
> During this process, the source file in the etc/nls subdirectory is first transformed
into a locale database using the localedef utility, then is converted back to a source file
using the locale utility.  This process is repeated twice more, with each following stage
relying on the source file from the previous itteration.  The test then concludes by checking
that the source files produced in the second and third stage are identical.
> On some platforms, including my local box, this process fails for most locales when the
localedef utility in the second stage is unable to process the output of the source file generated
by the locale utility in the first stage of the process.  Output from running the en_US.ISO-8859-1.sh
(wrapper) script with the '-d' flag on my box is attached as en_US.ISO-8859-1.sh.out.  The
failure message from the localedef utility in this case is as follows:
> Error 399: decimal value in the range [0, 255) expected: \d383
> When I search for the string '\d383' in the source file being parsed (attached as out.1),
I find it in the LC_COLLATE section.  It appears to me that either the output from the locale
utility doesn't use the correct range, or that the valid range for the parser in localedef
is incorrect.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message