Re: strptime() could hangs for hours

[Corinna Vinschen <vinschen at redhat dot com>]

On Apr  1 11:02, Howland Craig D (Craig) wrote:
> On Apr  1 04:59, Corinna Vinschen wrote:
> >> 2011-03-30  Craig Howland <...>
> >>
> >>      * libc/time/strptime.c:  ... limit
> >>      year to 1753 or later.
> >
> >Thanks for the patch.  I don't think it's right to limit the date
> >to >= 1753, though.  Think about it:
> >
> >  strptime ("Apr 01, 1489", "%b %d, %Y", tm_ptr);
> >
> >There's no good reason to treat this as wrong.  If anything, you could
> >skip the %[UVW] handling for dates < 1753.
> >
> >
> >Corinna
> >
> Corinna:
>      Based on your comment, I just looked a little bit more at the
> function overall and found another flaw:  it does not calculate the day
> of the week from other information, but only when there is one of the
> formats directly related to it.  So even if "6 Dec 2001 12:33:45",
> were given--which correctly, fully specifies sufficient information--the
> output would be incomplete because tm_wday would not have been set.

I don't think that's necessary.  Here's what SUSv4 says:

 "The strptime() function shall convert the character string pointed to
  by buf to values which are stored in the tm structure pointed to by tm,
  using the format specified by format.

  [...]

  It is unspecified whether multiple calls to strptime() using the same
  tm structure will update the current contents of the structure or
  overwrite all contents of the structure. Conforming applications
  should make a single call to strptime() with a format and all data
  needed to completely specify the date and time being converted."

And here's the glibc man page:

 "In principle, this function does not initialize tm but only stores  the
  values  specified.  This means that tm should be initialized before the
  call.  Details differ a bit between different Unix systems.  The  glibc
  implementation  does  not  touch  those fields which are not explicitly
  specified, except that it recomputes the tm_wday and tm_yday  field  if
  any of the year, month, or day elements changed.

So there's no reason to expect that any tm fields except those
specified by the format specifier are touched at all.

>      Perhaps we ought to glance at FreeBSD to see if their's is not so
> bug-ridden.

Cygwin is using a strptime implementation based on the NetBSD version,
but with additional code to handle the %E and the %O modifiers.

Maybe you would like to fetch it from the sourceware repository and
make the %E/%O handling depend on some build-time definition for
small targets?

However, for a first cut I think your patch is sufficient, provided
you drop the hard 1753 border.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat