Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (nike.apache.org: domain of msebor@gmail.com designates
 209.85.220.54 as permitted sender)
Message-ID: <5069B17B.5040003@gmail.com>
Date: Mon, 01 Oct 2012 09:06:35 -0600
From: Martin Sebor <msebor@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: dev@stdcxx.apache.org
CC: Liviu Nicoara <nikkoara@hates.ms>
Subject: Re: STDCXX-970 and locale tests
References: <50678544.3000403@hates.ms> <50699355.7030201@hates.ms>
In-Reply-To: <50699355.7030201@hates.ms>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 10/01/2012 06:57 AM, Liviu Nicoara wrote:
> On 09/29/12 19:33, Liviu Nicoara wrote:
>> [...] all locale tests are supposed to be run without
>> RWSTD_LOCALE_ROOT defined?
>
> I have looked in other tests and they seem to either:
>
> 1. Create their own "synthetic" locales from hard-coded sources.
> 2. Create true locales from STDCXX sources.
>
> Both are placed at runtime in temporary directories, then the test sets
> RWSTD_LOCALE_ROOT, and the localization library picks them from there.
> Setting the RWSTD_LOCALE_ROOT directory beforehand (even to a correct
> location) is unexpected.

I suspect the setting is simply ignored (overwritten by the test).

>
> Also, I see that the localization tests do not make use of input files,
> unlike the older Rogue Wave tests. Is that a policy going forward that
> the tests do not make use of external input files?

The tests hardcode locale values in order to guarantee consistent
results, even if the external locale databases change. There also
is a makefile target that builds all the stdcxx locales. That's
just to exercise the locale utility programs. I think there also
should be a test that uses localedef to build a subset of these
locales, runs the locale utility to dump the contents of the built
database, and then localedef again to rebuild the database. Then
it compares the result of the first and second build (or it may
do three stages to normalize things) to make sure they match.

Martin

>
> Thanks,
> Liviu