stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <tvi...@quovadx.com>
Subject RE: [PATCH] Update test 22.locale.time.put.mt.cpp to validate results [take 2]
Date Mon, 13 Aug 2007 17:14:24 GMT
 

Martin Sebor wrote:
>
>Now that I've committed the patch... I have a question about the bit
>below that I noticed too late:
>
>[...]
>> @@ -160,19 +214,117 @@
>>  static int
>>  run_test (int, char**)
>[...]
>> +    const char* const possible_locale_options[] = {
>> +        locale_list, "C\0", 0
>> +    };
>
>Is the purpose of this code to exercise the "C" locale in addition
>to all the named locales returned from rw_locales()?
>
>If so, it's a valuable enhancement to the test since the base facet
>(i.e., time_put as opposed to time_put_byname) wasn't necessarily
>being exercised by the test before this change. Good catch!
>
Well that isn't the intent and I don't think that is what it does.

There was some discussion [http://tinyurl.com/2jkqmd] about what to do
in the case where the no valid locale could be located, either because
the user specified invalid locale names, or because the system didn't
have any valid locales. So the test attempts to use the provided or
enumerated list of locales, and if none of them could be loaded, the "C"
locale will be used. If, after attempting to load the "C" locale, no
locale could be loaded a rw_fatal diagnostic will be issued.

>
>That said, I'm not quite happy with how this solution is "grafted"
>on to the current general mechanism we use to obtain the list of
>locales to test. First, the list of locales the test says (in the
>call to rw_info()) it exercises doesn't include this locale.
>
The list of locales displayed is the list of locales that are actually
used. If no valid provided or enumerated locale could be created, the
"C" locale would be used. In that case the rw_info diagnostic would
indicate that the "C" locale was the only locale used.

As suggested below, we could modify rw_locales method to optionally
insert the "C" locale to the head of the locale list. This would ensure
that the test always had at least one valid locale when invoked without
the --locales option. It would also nicely generate an rw_fatal
diagnostic if the user didn't provide a list of valid locales.

>Second,
>there's no way to disable it using the --locales option.
>
Agreed. As is, it is only a fallback. If we modified the behavior as
suggested, then we should make an option to enable or disable it.

>Finally,
>it's a chunk of code that will likely end up being repeated in all
>the locale tests and so it's a perfect candidate for an enhancement
>to the test driver.
>
Yes, it will get repeated. Notice it was repeated in the three tests I
wrote last week. Ugh.

>
>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?

>Martin
>
>

Mime
View raw message