Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates
 209.85.198.188 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=dC1RPeF3cbU9r10YE3O2Ng/5xsVkSHku5vvwQgMhtibkzClrHQ8yZddFQAEs8Ivl8Z8NTSIaWU0ddMrLyLctQDtqkiClYvRLo+LHmjR+L1tA31MXgDx6xPdPDWrZoAQH558afm4I1tDqZoza6TaJoLVHF1Q5KF6A/K8aSSp6/qM=
Message-ID: <477C04D7.7090002@roguewave.com>
Date: Wed, 02 Jan 2008 14:40:39 -0700
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: low hanging fruit while cleaning up test failures
References: <47321834.8050203@roguewave.com> <13637191.post@talk.nabble.com>
 <47323B7D.9030104@roguewave.com> <13659097.post@talk.nabble.com>
 <47348DC2.8070703@roguewave.com> <14457668.post@talk.nabble.com>
 <14561904.post@talk.nabble.com> <477BC336.20004@roguewave.com>
 <14584842.post@talk.nabble.com> <477BF27B.5060308@roguewave.com>
 <14585914.post@talk.nabble.com>
In-Reply-To: <14585914.post@talk.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>

Travis Vitek wrote:
> 
> 
> Martin Sebor wrote:
>> Travis Vitek wrote:
>>>
>>> Martin Sebor wrote:
>>>> Travis Vitek wrote:
>>>>> Martin Sebor wrote:
>>>>>> I added a new function, rw_fnmatch(), to the test driver. It behaves
>>>>>> just
>>>>>> like the POSIX fnmatch() (the FNM_XXX constants aren't implemented
>>>>>> yet). While the main purpose behind the new function is to support
>>>>>> STDCXX-683 it should make it easier to also implement a scheme like
>>>>>> the one outlined below.
>>>>>>
>>>>>> Travis, feel free to experiment/prototype a solution :)
>>>>>>
>>>>>> Martin
>>>>>>
>>>>> What expression should be used to get an appropriate set of locales for
>>>>> a
>>>>> given platform? I can't really expect a filter for all UTF-8 locales to
>>>>> work
>>>>> on all platforms as some don't have those encodings available at all.
>>>>> If
>>>>> I
>>>>> filter by language, then I may be limiting the testing to some always
>>>>> correct subset. Is that acceptable for the MT tests?
>>>> I think the MT ctype tests just need to exercise a representative
>>>> sample of multi-byte encodings (i.e., MB_CUR_MAX between 1 and
>>>> MB_LEN_MAX). There already is some code in the test suite to find
>>>> locales that use these encodings, although it could be made more
>>>> efficient. I don't know how useful rw_fnmatch() will turn out to
>>>> be in finding these codesets since their names don't matter.
>>>>
>>>> Martin
>>>>
>>>>> Travis
>>>
>>> Actually, I think I meant to say single threaded tests. Those are the
>>> ones
>>> that currently test every locale. The multi-threadede tests already test
>>> a
>>> subset of locales, though the method for selecting those locales may vary
>>> between tests.
>>>
>>> I don't think it is right to test a fixed set of locales based on
>>> language,
>>> country, or encoding. If you agree, then we probably agree that the
>>> proposed
>>> enhancement doesn't actually do anything useful [and I've wasted a bunch
>>> of
>>> time]. If this is the case, then we need to propose another solution for
>>> selecting locales.
>> I think testing a small subset of installed locales should be enough.
>> In fact, for white box testing of the ctype facets, exercising three
>> locales, "C" and two named ones, should be sufficient.
>>
>>> If I am wrong, and it is useful for testing [and more specifically how it
>>> would be useful for fixing STDCXX-608], then I'd like to hear how.
>> What do you propose?
>>
>> Martin
>>
>>
> 
> Okay. I can live with that. Then the issue now becomes deciding which
> additional locales to test. How about just testing all Spanish and German
> locales?

I'd make sure at least one of them uses a multibyte encoding. Maybe
zh_CN.GB18030? (with MB_CUR_MAX of 4)?

Martin