incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: expectation vs requirements for locale facets
Date Tue, 21 Aug 2007 23:56:30 GMT
Travis Vitek wrote:
>  
> 
> Martin Sebor wrote:
>> The C and C++ standards only specify the requirements on the "C"
>> locale and leave the localized behavior unspecified. So pretty
>> much anything goes.
>>
> 
> I don't know how you can say that with a straight face.

How do you know what face I made when I said it? ;-)

> The C++ standard
> says that time_put<>::put() treats the format string like strftime().
> The C and POSIX specifications both define the output for strftime() for
> each of the required format specifiers. The numeric values are pretty
> strictly specified, and the non-numeric ones [%b as an example] are
> supposed to be defined by the specified locales LC_TIME category.

You're right about %e -- the C standard leaves no wiggle room
there. It must expand to the day of the month with single-digit
numbers having to be preceded by a space. But %b (or %x and %X)
can expand to anything at it need not even be parseable.

[...]
> I guess you could interpret that as vague. I mean they don't explicitly
> say you can't try to emulate strptime(). Of course they don't explicitly
> say you should attempt to either.
> 
> They do, on the other hand, say that the put() should behave
> consistently with strftime(), and that get_*() should be able to read
> the output of put() for a given format.

Yes, but don't the get_time() and get_date() functions also
say that they only parse the output produced by "%H:%M:%S"
and "%m/%d/%y" (or some such combination of the individual
directives)?

Btw., the next standard contains some useful enhancements
to the time_get facet:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2321.html

[...]
> Yeah, I've made a testcase using strptime(), but it passes on most
> environments I've tested. Source...
> 
[test program snipped]
> 
> The strptime() function is clearly skipping leading whitespace with the
> '%e' flag on those platforms that allow this test to pass. Here is a
> quick test matrix

Interesting. So strptime("%e") swallows the leading space on all
of these platforms (plus AIX) except HP-UX. I'd be inclined to
say that they're all buggy, but that wouldn't help us much. I
think I'll need to ask on the POSIX list what the intended
behavior actually is. They usually tend to standardize existing
practice so even if the intent is not to consume whitespace since
pretty much all platforms do, I suspect they'll either go with it
or make it unspecified.

Martin

PS I enhanced your test case to exercise the behavior in all
locales installed on each system and it still passed on the
two platforms I tried (AIX and Linux) and failed on HP-UX.

Mime
View raw message