rather than [0,61]. The standard has removed mention of double leap seconds.
The standard has give the following rationale in the time.h man page:
"The range [0,60] seconds allows for positive or negative leap seconds.
The formal definition of UTC does not permit double leap seconds, so all
mention of double leap seconds has been removed, and the range shortened
from the former [0,61] seconds seen in previous versions of POSIX."
just ...
ptrdiff_t nitems_max = PTRDIFF_MAX - WORK_AROUND_QTBUG_53071;
ptrdiff_t amax = nitems_max < SIZE_MAX ? nitems_max : SIZE_MAX;
which is just fine if you think about it a little, Unfortunately,
in our zealous effort to never leave a ggc warning unused, and to
treat all of the warnings as fatal errors, that code falls foul of the
"you must not compare an unsigned value with a signed value" warning.
nitems_max is a (signed) largish positive integer (obviously, by
inspection). If it is less than SIZE_MAX then amax is just nitems_max.
In the unlikely case that size_t has less bits than ptrdiff_t so
SIZE_MAX is smaller, amax is limited to SIZE_MAX (which in that case
is known to fit in the ptrdiff_t and to remain positive).
To pacify gcc (and the way the build system uses it), casts are
required. Unfortunately the cast that was installed here was to
convert SIZE_MAX to a ptrdiff_t. Unfortunately when ptrdiff_t has
the same number of bits (or less) as size_t (ie: the common case)
but is signed, (ptrdiff_t)SIZE_MAX is just a fancy way of writing -1.
Rearrange the casting in a way that keeps the original intent
of the code for us (it is actyaly now incorrect if size_t has less
bits than a ptrdiff_t) and keeps gcc happy, all at the same time.
What a mess.
SIZE_MAX is the max value of a size_t (and is unsigned) so when converted
to a ptrdiff_t (int) becomes -1. That's not what the code was attempting
to achieve.
This will be reported upstream to the tzcode maintainers, and we'll see
what variation appears in tzcode2016j ...
Until then, the older code always worked for us, so it will do for now.
This should fix the broken i386 build.
This is actually unnecessary as the call in question uses only fields
that have been set explicitly, but good practice regardless and it's
not like it's on a performance-critical path.
Changes affecting code
localtime no longer mishandles America/Anchorage after 2037.
(Thanks to Bradley White for reporting the bug.)
The localtime module allows the variables 'timezone', 'daylight',
and 'altzone' to be in common storage shared with other modules,
and declares them in case the system <time.h> does not.
(Problems reported by Kees Dekker.)
On platforms with tm_zone, strftime.c now assumes it is not NULL.
This simplifies the code and is consistent with zdump.c.
(Problem reported by Christos Zoulas.)
Changes affecting documentation
The tzfile man page now documents that transition times denote the
starts (not the ends) of the corresponding time periods.
(Ambiguity reported by Bill Seymour.)
