this bug goes back to commit 1cc81f5cb0df2b66a795ff0c26d7bbc4d16e13c6
where zoneinfo file support was first added. in scan_trans, which
searches for the appropriate local time/dst rule in effect at a given
time, times prior to the second transition time caused the -1 slot of
the index to be read to determine the previous rule in effect. this
memory was always valid (part of another zoneinfo table in the mapped
file) but the byte value read was then used to index another table,
possibly going outside the bounds of the mmap. most of the time, the
result was limited to misinterpretation of the rule in effect at that
time (pre-1900s), but it could produce a crash if adjacent memory was
not readable.

the root cause of the problem, however, was that the logic for this
code path was all wrong. as documented in the comment, times before
the first transition should be treated as using the lowest-numbered
non-dst rule, or rule 0 if no non-dst rules exist. if the argument is
in units of local time, however, the rule prior to the first
transition is needed to determine if it falls before or after it, and
that's where the -1 index was wrongly used.

instead, use the documented logic to find out what rule would be in
effect before the first transition, and apply it as the offset if the
argument was given in local time.

the new code has not been heavily tested, but no longer performs
potentially out-of-bounds accesses, and successfully handles the 1883
transition from local mean time to central standard time in the test
case the error was reported for.

previously, the contents of the TZ variable were considered a
candidate for a file/path name only if they began with a colon or
contained a slash before any comma. the latter was very sloppy logic
to avoid treating any valid POSIX TZ string as a file name, but it
also triggered on values that are not valid POSIX TZ strings,
including 3-letter timezone names without any offset.

instead, only treat the TZ variable as POSIX form if it begins with a
nonzero standard time name followed by +, -, or a digit.

also, special case GMT and UTC to always be treated as POSIX form
(with implicit zero offset) so that a stray file by the same name
cannot break software that depends on setting TZ=GMT or TZ=UTC.

the v1 zoneinfo format with 32-bit time is deprecated. previously, the
v2 parsing code was only used if an exact match for '2' was found in
the version field of the header. this was already incorrect for v3
files (trivial differences from v2 that arguably didn't merit a new
version number anyway) but also failed to be future-proof.

since commit 38143339646a4ccce8afe298c34467767c899f51, the condition
sizeof(time_t) > 4 is always true, so there is no functional change
being made here. but semantically, the 64-bit tables should always be
preferred now, because upstream zic (zoneinfo compiler) has quietly
switched to emitting empty 32-bit tables by default, and the resulting
backwards-incompatible zoneinfo files will be encountered in the wild.

as the outcome of Austin Group tracker issue #62, future editions of
POSIX have dropped the requirement that fork be AS-safe. this allows
but does not require implementations to synchronize fork with internal
locks and give forked children of multithreaded parents a partly or
fully unrestricted execution environment where they can continue to
use the standard library (per POSIX, they can only portably use
AS-safe functions).

up until recently, taking this allowance did not seem desirable.
however, commit 8ed2bd8bfcb4ea6448afb55a941f4b5b2b0398c0 exposed the
extent to which applications and libraries are depending on the
ability to use malloc and other non-AS-safe interfaces in MT-forked
children, by converting latent very-low-probability catastrophic state
corruption into predictable deadlock. dealing with the fallout has
been a huge burden for users/distros.

while it looks like most of the non-portable usage in applications
could be fixed given sufficient effort, at least some of it seems to
occur in language runtimes which are exposing the ability to run
unrestricted code in the child as part of the contract with the
programmer. any attempt at fixing such contracts is not just a
technical problem but a social one, and is probably not tractable.

this patch extends the fork function to take locks for all libc
singletons in the parent, and release or reset those locks in the
child, so that when the underlying fork operation takes place, the
state protected by these locks is consistent and ready for the child
to use. locking is skipped in the case where the parent is
single-threaded so as not to interfere with legacy AS-safety property
of fork in single-threaded programs. lock order is mostly arbitrary,
but the malloc locks (including bump allocator in case it's used) must
be taken after the locks on any subsystems that might use malloc, and
non-AS-safe locks cannot be taken while the thread list lock is held,
imposing a requirement that it be taken last.

this change lifts undocumented restrictions on calls by replacement
mallocs to libc functions that might take these locks, and sets the
stage for lifting restrictions on the child execution environment
after multithreaded fork.

care is taken to #define macros to replace all four functions (malloc,
calloc, realloc, free) even if not all of them will be used, using an
undefined symbol name for the ones intended not to be used so that any
inadvertent future use will be caught at compile time rather than
directed to the wrong implementation.

This is like SIGEV_SIGNAL, but targeted to a particular thread's
tid, rather than the process.

this makes the code slightly smaller and eliminates timer_create from
relevance to possible future changes to multithreaded fork.

the barrier of a_store isn't technically needed here, but a_store is
used anyway for internal consistency of the memory model.

this was leftover from when the actual SIGEV_THREAD timer logic was in
the signal handler. commit 5b74eed3b301e2227385f3bf26d3bb7c2d822cf8
replaced that with use of sigwaitinfo, with the actual signal left
blocked, so the no-op signal handler was no longer serving any
purpose.

the signal disposition reset to SIG_DFL is still needed, however, in
case we inherited SIG_IGN from a foreign-libc process.

TZ containg a timezone name with >TZNAME_MAX characters currently
breaks musl's timezone parsing. getname() stops after TZNAME_MAX
characters. getoff() will consume no characters (because the next
character is not a digit) and incorrectly return 0. Then, because
there are remaining alphabetic characters, __daylight == 1, and
dst_off == -3600.

getname() must consume the entire timezone name, even if it will not
fit in d/__tzname, so when it returns, s points to the offset digits.