stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <tvi...@quovadx.com>
Subject RE: expectation vs requirements for locale facets
Date Wed, 22 Aug 2007 17:15:57 GMT
 

>Martin Sebor wrote:
>
>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? ;-)
>
Actually I was picturing you in a grey suit, a shaved head and a white
persian cat. Muhaha. Muhaha. :)

>
>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 as it need not even be parseable.
>
Not sure about that. If you write a date out using POSIX strftime(...,
"%x", ...) and you can read it back using POSIX strptime(..., "%x",
...), then I would hope that you could do so using time_put and
time_get. I can see that there might be issues if the date is formatted
using some composition of specifiers [%Y/%m/%d] and you attempt to parse
that with a different specifier [%x]. I can also imagine that there
could be issues with multi-byte characters, but I'm attempting to ignore
those for the time being.

>[...]
>> 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)?

No, I haven't seen anything that indicates that is the case. The only
requirement that I've seen is that on do_get_[date,time]() that I've
quoted several times. It just says that it must extract the struct tm
members and read the format characters used by time_put<>::put to
produce the format specified by 'x' ['X'] or until it encounters an
error. With many locales you could wirte %m/%d/%y and it would happen to
be readable with time_get<>::get_date(), but that does not appear to be
a requirement.

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

Ah, yes. I now see why we are the linked to strptime(). :)

Now this begs the question. I saw that we had the time_get<>::get()
extension in there. I'm wondering if the mt test should just be using
this as all of the other get method variants end up invoking do_get() in
the end. It would simplify the test a little bit, but it really offers
no other benefit.

>> Yeah, I've made a testcase using strptime(), but it passes on most
>> environments I've tested.
>> 
>> 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.
>
It isn't just %e that exhibits this behavior. Adding leading whitespace
to all of the fields appears to work on the same platforms...

    const char* fmt = "-%H:%M:%S-%m/%e/%Y-";
    const char* buf = "- 1: 2: 3- 4/ 5/ 1906-";

>
>I'd be inclined to
>say that they're all buggy, but that wouldn't help us much.
>
Denial is the first step in the grieving process. :)

>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.
>
I imagine that we'll file a bug and start eating leading whitespace in
either case, right?

>

Travis

Mime
View raw message