Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Message-ID: <17948585.1156893383719.JavaMail.jira@brutus>
Date: Tue, 29 Aug 2006 16:16:23 -0700 (PDT)
From: "Martin Sebor (JIRA)" <jira@apache.org>
To: stdcxx-dev@incubator.apache.org
Subject: [jira] Assigned: (STDCXX-277) [locale] invalid LC_COLLATE output
 for weights > 255
In-Reply-To: <299696.1155916933823.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/STDCXX-277?page=all ]

Martin Sebor reassigned STDCXX-277:
-----------------------------------

    Assignee: Martin Sebor

> [locale] invalid LC_COLLATE output for weights > 255
> ----------------------------------------------------
>
>                 Key: STDCXX-277
>                 URL: http://issues.apache.org/jira/browse/STDCXX-277
>             Project: C++ Standard Library
>          Issue Type: Bug
>          Components: Utilities
>    Affects Versions: 4.1.2, 4.1.3
>         Environment: Multiple, including Linux 2.6.14.5 + gcc 3.2.3
>            Reporter: Andrew Black
>         Assigned To: Martin Sebor
>         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