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: local policy)
Message-ID: <46C0E3E9.8090304@roguewave.com>
Date: Mon, 13 Aug 2007 17:06:17 -0600
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: [PATCH] Update test 22.locale.time.put.mt.cpp to validate results
 [take 2]
References: <a648c5670708101402x2cf95594q7b70ed28091c8867@mail.gmail.com>
 <46BF913F.8000403@roguewave.com>
 <C8506D6098A6F545BA3745D0CE359E8301757BC2@qxvcexch01.ad.quovadx.com>
 <C8506D6098A6F545BA3745D0CE359E8301757BFE@qxvcexch01.ad.quovadx.com>
In-Reply-To: 
 <C8506D6098A6F545BA3745D0CE359E8301757BFE@qxvcexch01.ad.quovadx.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Travis Vitek wrote:
>  
> 
> Travis Vitek wrote:
>> Martin Sebor wrote:
>>> What do you think about this: let's change rw_locales() to always
>>> return a list of names that starts with "C". That way callers that
>>> don't want to exercise the "C" locale can simply skip past it while
>>> others will be guaranteed to exercise the classic locale.
>>>
>> Sounds good. If we all agee, then I'll make up a patch for rw_locales()
>> and for each of the tests that I added last week.
>>
>> I'm thinking that rw_locales should take a bool that indicates the "C"
>> locale should be included at the head of the list. Ideally the default
>> value would be true, but for compatibility it should be set to false.
>> Hmmm. I'm thinking false and the tests that want the new 
>> behavior can be
>> updated later.
>>
>> I will also need to add support for a command line option to enable or
>> disable this behavior. I'm thinking --use-c-locale=# or --no-c-locale#
>> depending on what we decide for the default value mentioned above. Does
>> that sound okay?
> 
> Ugh. What if the user provides both options --locales=en_US,es_MX and
> --use-c-locale? Should we attempt to add the "C" locale to the user
> supplied locale list, or should this only be something that is in effect
> when the user doesn't use --locales?

I wouldn't. If the user says --locales=en_US,es_MX then I'd trust
them to mean en_US and es_MX and not en_US, es_MX, and "C" :)

> 
> The second option is weird, but it makes the most sense. The user could
> easily just write --locales=en_US,es_MX,C if that is what they wanted.

Exactly!

Martin