From stdcxx-dev-return-4238-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org Wed Aug 08 22:06:13 2007 Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 16250 invoked from network); 8 Aug 2007 22:06:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 8 Aug 2007 22:06:13 -0000 Received: (qmail 50033 invoked by uid 500); 8 Aug 2007 22:06:12 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 49972 invoked by uid 500); 8 Aug 2007 22:06:12 -0000 Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: stdcxx-dev@incubator.apache.org Delivered-To: mailing list stdcxx-dev@incubator.apache.org Received: (qmail 49961 invoked by uid 99); 8 Aug 2007 22:06:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Aug 2007 15:06:12 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [208.30.140.160] (HELO moroha.quovadx.com) (208.30.140.160) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Aug 2007 22:06:09 +0000 Received: from qxvcexch01.ad.quovadx.com ([192.168.170.59]) by moroha.quovadx.com (8.13.6/8.13.6) with ESMTP id l78M5lQ0030762 for ; Wed, 8 Aug 2007 22:05:47 GMT Received: from [10.70.3.113] ([10.70.3.113]) by qxvcexch01.ad.quovadx.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 16:04:58 -0600 Message-ID: <46BA3E5B.1080700@roguewave.com> Date: Wed, 08 Aug 2007 16:06:19 -0600 From: Martin Sebor Organization: Rogue Wave Software, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1 MIME-Version: 1.0 To: stdcxx-dev@incubator.apache.org Subject: Re: [PATCH] Update test 22.locale.time.put.mt.cpp to validate results References: <46B8A1D6.8050706@roguewave.com> <46B90C21.8060108@roguewave.com> <46B944ED.10602@roguewave.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2007 22:04:58.0924 (UTC) FILETIME=[29345EC0:01C7DA08] X-Virus-Checked: Checked by ClamAV on apache.org Travis Vitek wrote: > > > Martin Sebor wrote: >> A test failure should indicate that there is a problem with >> the library, >> not that the environment system is not equipped to exercise it. > > Agreed. > >> When >> there's only one locale installed on a system (the "C" locale must >> always be present) that's not a problem we can do much about. All it >> means is that we can't tell if the library would work correctly if >> there were more than one locale. So I think in this case the test >> should just run all threads in the "C" locale. It won't be a very >> useful test but it'll be better than nothing, don't you agree? >> > > The only issue I would have is when the test is run manually. There > is a command line argument to explicitly specify the locales to use, > and if none of them are available I think I'd expect the test to exit > immediately with an error. You mean when the user specifies --locales="foo bar" and one or more of them isn't available the test should give an error? Hmm, I agree that we should give some indication that one (or more) of the locales are unavailable in this case but think I would still prefer a warning to a hard error, simply because I see no harm in being robust (not every locale that /usr/bin/locale -a spits out is valid, so having the test weed out the bad ones can be useful when scripting things). Do you have a reason for wanting it to be an error? > > I can live with defaulting to the C locale as long as there is a > warning, which is already provided. > >> Btw., the locale thread safety tests currently only exercise the >> implementation when using the native (libc) locales. There's a big >> chunk of code that deals with our own locales that's not being >> tested. At some point we'll need to enhance the tests to exercise >> this functionality as well. >> > > I'm not sure what needs to be added for this enhancement. Could you > name a test or two that does this, or point me to the APIs I need > to be using? The API is the same. The machinery is enabled automatically by pointing the RWSTD_LOCALE_ROOT environment variable at the root of the stdcxx locale database tree and referencing locales installed under it by name (or pathname). Most of the locale tests, including 22.locale.time.put.cpp, exercise both implementations. Martin