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 Mon, 20 Aug 2007 04:08:46 GMT
Travis Vitek wrote:
>  
> 
> Travis Vitek wrote:
>> Travis Vitek wrote:
>>> The problem is that some locales pad their date/time output with
>>> whitespace [like '7. 6. 1988' or ' 7.6.1988'] and I'm unable to use
>>> num_get<>::get_[time,date] to read what is written by 
>>> num_put<>::put. It
>>> is my understanding that I should be able to do so. Is this a bug, a
>>> known issue, or is it acceptable behavior that I need to code 
>> around in
>>> the test?
>> Whoops, obviously I am talking about the time_[get,put] facets here.
>>
> 
> Okay, so I've done the required research. These are the relevant
> sections of the standard that I was able to find.
> 
>   [22.2.5.1 p1]  Each  get  member parses  a  format  as  produced by a
>   corresponding format specifier to  time_put<>::put.  If  the sequence
>   being parsed maches  the correct format, the corresponding members of
>   the  struct tm  argument are  set  to  the values used to produce the
>   sequence; otherwise either an error is reported or unspecified values
>   are assigned.  
> 
>   [22.2.5.1.2 p2] Effects: Reads characters starting at  s until it has
>   extracted  those  struct tm members, and remaining format characters,
>   used by  time_put<>::put  to produce  the  format specified by 'X' or
>   until it encounters an error.
> 
> Unless I'm missing something obvious, it appears that the output of the
> time_put<> facet is required to be parseable by the time_get<> facet.

Yes. But notice the text doesn't say anything about time_put_byname or
time_get_byname ;-) The C++ standard (or even the C standard for that
matter) isn't going to of help here.

> Of
> course that isn't what I'm seeing.

Test case?

> 
> One case that fails is the weekday '%e'. With some locales '%x' expands
> out to '%m/%e/%Y'. Anyways, when putting the data,
> __rw_get_time_put_data() correctly sets the field width to 2. When we
> attempt to get the data back out of the stream, no width is specified.
> There is no code in place in the get_date() call stack to deal with
> width, and the block of code that does the actual parsing doesn't have
> any concept of field width either [_time_get.cc:284].

It's hard to say from just looking at the code (and I haven't looked
very carefully). In general, we [try to] to implement the POSIX
semantics, so if it works with strptime()/strftime() it should work
with our time_put_byname/ time_get_byname.

> 
> Worse yet is that the tests actually verify this bad behavior. The
> 22.locale.time.get test verifies that the '%e' format fails if there is
> any leading whitespace.

If we test this behavior it's gotta be right ;-) Where does POSIX
say leading spaces must be skipped? I see this under %e: Equivalent
to %d. And under %d: The day of the month [01,31]; leading zeros
are permitted but not required. Nothing about ignoring spaces.

> 
>   // %e Equivalent to %d; leading zeros are permitted but not required.
>   STEP ("%e: equivalent to %d");
>   TEST (T (0, 0, 0,  1),  "01", 2, "e", 0, Eof);
>   TEST (T (0, 0, 0,  9),   "9", 1, "e", 0, Eof);
>   TEST (T (0, 0, 0, 31),  "31", 2, "e", 0, Eof);
>   TEST (T (0, 0, 0,  0),   "0", 1, "e", 0, Eof | Fail);
>   // leading whitespace not allowed
>   TEST (T (0, 0, 0,  0),  " 2", 0, "e", 0, Fail);  // *** problem
>   TEST (T (0, 0, 0,  0),  "99", 2, "e", 0, Eof | Fail);
> 
> The 22.locale.time.put test verifies the leading space is there when
> writing the '%e' format.
> 
>   // %e: the day of the month as a decimal number (1-31);
>   //     a single digit is preceded by a space. [tm_mday]
>   rw_info (0, 0, __LINE__, "%%e: the day of the month as a decimal
> number");
>   TEST (T (), "%e", 0, 0, ' ', "%e");
>   TEST (T (), "%e", 0, 0, ' ', " 1"); // *** problem
>   TEST (T (), " 1", 0, 0, ' ', "%e"); // *** problem
>   TEST (T (-1), "%e", 0, 0, ' ', "%e");
> 
> Feedback?

Without too much research, my first take on this is that it will
probably fall under the "not every output format can be parsed"
category. But we need to do some more reading to confirm this
hypothesis.

Martin


Mime
View raw message