Re: winsup/cygwin/libc/strptime.cc(__strptime) strptime %F issue

[Brian Inglis <Brian dot Inglis at SystematicSw dot ab dot ca>]

On 2017-08-23 12:51, Brian Inglis wrote:
> On 2017-07-23 22:07, Brian Inglis wrote:
>> On 2017-07-23 20:09, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
>>>> But that's just scanning a decimal integer to time_t.
>>> It's not a question of whether I can or can't convert a string into an 
>>> integer, rather it's a question about portability of code that uses %s
>>> for both functions and expects it to work unchanged in the Cygwin
>>> environment.
>>> Also, strptime() was designed to be a reversal to strftime() (from the 
>>> man-pages: the strptime() function is the converse function to
>>> strftime(3)) so both are supposed to "understand" the same basic set of
>>> formats. Because of Cygwin's strptime() missing "%s", the following also
>>> does not work even from command line:
>>> $ date +"%s" | strptime "%s"
> Testing revealed a separate issue with %F format which I will follow up on in
> a different thread.
Actually same thread, different subject.

Cygwin strptime(3) (also strptime(1)) fails with default width, without an
explicit width, because of the test in the following code:

case 'F':	/* The date as "%Y-%m-%d". */
	{
	  LEGAL_ALT(0);
	  ymd |= SET_YMD;
	  char *tmp = __strptime ((const char *) bp, "%Y-%m-%d",
				  tm, era_info, alt_digits,
				  locale);
	  if (tmp && (uint) (tmp - (char *) bp) > width)
	    return NULL;
	  bp = (const unsigned char *) tmp;
	  continue;
	}

as default width is zero so test fails and returns NULL.

Simple patch for this as with the other cases supporting width is to change the
test to:

	  if (tmp && width && (uint) (tmp - (char *) bp) > width)

but this does not properly support [+0] flags or width in the format as
specified by glibc (latest POSIX punts on %F) for compatibility with strftime(),
affecting only the %Y format, supplying %[+0]<w-6>F, to support signed and zero
filled fixed and variable length year fields in %F format.

So do you want compatible support or just the quick fix?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada