strptime: fix %C, %y, and %Y permutations

[yuripv]

Summary

Found by tests/lib/libc/time (not shipped yet).

We fail the following century/year test cases:

strptime("x2084y", "x%C%yy", tm): incorrect tm_year: expected: 184, but got: 84
strptime("x8420y", "x%y%Cy", tm): incorrect tm_year: expected: 184, but got: 100
strptime("%20845", "%%%C%y5", tm): incorrect tm_year: expected: 184, but got: 84

The problem here is that we don't check if we have %C conversion in the format string when processing %y, and as %C can come *after* %y, fix this by calculating tm_year after we have finished processing the format string.

Also do NOT fail if resulting tm_year is negative based on the APPLICATION USAGE in http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html (glibc does the same):

tm_year is a signed value; therefore, years before 1900 may be represented.

Konstantin, it's not clear to me who else can/should be added to reviewers, need an advise here (hackers@?).

[kib]

So we apparently have Y2K bug ?

lib/libc/stdtime/strptime.c

98 ↗

(On Diff #49112)

style(9) requests that initialization is not done in declarations.

609 ↗

(On Diff #49112)

... and use flags instead of the comparision with -1, in style of other places ?

[yuripv]

lib/libc/stdtime/strptime.c

609 ↗

(On Diff #49112)

There's a problem with using flags -- they are set by e.g. %c, which does NOT modify century/year by itself, and rather uses recursion.

[yuripv]

lib/libc/stdtime/strptime.c

98 ↗

(On Diff #49112)

Will change, it's just that surroundings not following the rule made me forget about it :-)

[yuripv]

style

[yuripv]

In D17550#374655, @kib wrote:

So we apparently have Y2K bug ?

If you mean the negative values for tm_year, then it likely should be called Y1.9K bug. Otherwise, we seem to have followed the standard, just didn't care about %C and %y both appearing in the format string in arbitrary order.

[kib]

In D17550#374670, @yuripv wrote:

In D17550#374655, @kib wrote:

So we apparently have Y2K bug ?

If you mean the negative values for tm_year, then it likely should be called Y1.9K bug. Otherwise, we seem to have followed the standard, just didn't care about %C and %y both appearing in the format string in arbitrary order.

I mean that %y%C leads to invalid century.

[yuripv]

In D17550#374675, @kib wrote:

In D17550#374670, @yuripv wrote:

In D17550#374655, @kib wrote:

So we apparently have Y2K bug ?

If you mean the negative values for tm_year, then it likely should be called Y1.9K bug. Otherwise, we seem to have followed the standard, just didn't care about %C and %y both appearing in the format string in arbitrary order.

I mean that %y%C leads to invalid century.

Ah, it certainly looks like that, yes, but really, we only get the value from whichever conversion comes last, %C or %y.