stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <>
Subject RE: expectation vs requirements for locale facets
Date Mon, 20 Aug 2007 10:31:40 GMT
>Martin Sebor wrote:
>Yes. But notice the text doesn't say anything about time_put_byname or
>time_get_byname ;-)

Well, the standard doesn't say much at all about the *_byname<>
facets. All it really says about them is

  [ p4] For some standard facets a standard "..._byname" class,
  derived from it, implements the virtual function semantics equivalent
  to the facet of the  locale constructed by  locale(const char*)  with
  the same name.  Each such  facet provides  a constructor that takes a
  const char*  argument which  names the  locale,  and a refs argument,
  which is passed to the base class constructor. [...]

So, if I'm reading that right, the *_byname<> facet classes are just
there to prevent the user from having to instantiate a std::locale

> The C++ standard (or even the C standard for that
> matter) isn't going to of help here.

Wait. Say what now? I'm not sure what you're trying to tell me here.
If the C++ Standard says that these facets read or write years as
roman numerals, then they should probably do so, regardless of what
any other standard document requires. I think this will actually get
cleared up in a few seconds...

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

Yeah. See attachment. Only tested on Win32/VC8 and Linux/GCC.

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

Well, there's the problem right there. The standard requires that the
time_put<> facet format its output according to the POSIX function
strftime(), with the option for supporting extensions. It makes no
indication that the time_get<> facet should read data in such a way as
to be compatible with strptime(). The only thing I see that says
anything about the format expecte by time_get<> is here...

  [ 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. note.232)

  232) In other words, user confirmation is required for reliable
  parsing of user-entered dates and times, but *machine-generated
  formats can be parsed reliably.* This allows parsers to be
  aggressive about interpreting user variations on standard formats.
  [emphasis added]

This paragraph says that time_get<>::get_date() is supposed to process
the output of time_put<>::put(..., 'x').

  [ p4] 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.

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

Absolutely. The docs for POSIX strftime()...

  %d Replaced by the day of the month as a decimal number [01,31]. [ tm_mday]
  %e Replaced by the day of the month as a decimal number [1,31]; a
single digit is preceded by a space. [ tm_mday]

Here is the problem. The docs for POSIX strptime()...

  %d The day of the month [01,31]; leading zeros are permitted but not
  %e Equivalent to %d.

So strftime() isn't even compatible with strptime() when it comes to '%e'.

>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

Unfortunately, without consistent input/output it is going to be
difficult for this multi-threading test to verify that no data
corruption is occuring with arbitrary locales. Hopefully there is some
system in place that allows us to explicitly specify which locales are
to be used for a test.


View raw message