The problem is that the tm_year field of "struct tm" is just an "int"
(per POSIX), and thus time_t values > 2^31*60*60*24*365 cannot
be converted. This made mktime(3) fail even if no such large time values
were passed in by user code because the algorithm does a binary search
over the time_t range which fails if a probe value cannot be converted.
To fix this, limit the time_t range to be scanned to 55 bits (which
is a bit on the safe side, but still good until y570855533).
This is more a stopgap fix, the overflow should be checked for
at other places as well (eg localtime(3)), and there are some more
limitations in timezone parsing code.
- While here, add all the rest of gnu extensions: %g, %G, %u.
- Fix long standing bug where %Z would not work because "private.h" was
not included. (Hi Brian!)
suppose they were legal before, but lint was unhappy about them. It
was probably unhappy for the wrong reasons, but I think it certainly
wasn't something one would want anyway. Declaring a string of length
three to have storage of length three without room for the nul is
asking for trouble even if it does work in context, and there was no
reason not to state how many days there are in a week or months in a
year -- they aren't onerous and aren't going to change.
NOTE: If this code isn't being synced with the central TZCODE stuff,
it probably should be KNFed etc. It is full of K&R declarations,
register, lots of eccentricities, etc.
I think this is enough to get rescue_tiny to fit again.
While there fix some bugs:
- %y failed to subtract 1900 from tm_year
- %p (am/pm) only worked at the end of the string
- %E% was treated at %% (ie match a % character)
regression test being added....
initialize it. However, instead of using what is suggested in this code
path, attempt get it right for DST as well. Addresses PR standards/21722
from Richard Earnshaw.
ginsbach