GitLab

Follow-on change from http://b/31848040.

Test: *time* tests.
Change-Id: I3f1c9ce19b90f6f8c1ac6e0753e3fed0ff63c0b4

Android uses one large file of tzdata, so the "read up to the maximum
possible length of a valid tzfile" code in upstream localtime.c is
broken: there is always data after the current tzfile (even the
last tzfile is followed by the zone.tab data). This patch passes the
exact length through to the read(2) call so we don't over-read, rather
than have to rewrite upstream code that measures back from the "end" of
the tzfile.

The old code failed the existing time.strftime_null_tm_zone test after
updating to tzdata2016g.

Bug: http://b/31848040
Test: time.strftime_null_tm_zone
Change-Id: Iee059b5a8c051bd4952cfd80f02b00d83e489d5e

We need to make a clearer distinction for bionic on the host. This patch
doesn't fully address things like "should host bionic try to talk to netd?"
for now, but is a step in the right direction.

Bug: http://b/31559095
Test: bionic tests.
Change-Id: I49812f8b75d9d78c4fd8a8ddf5df1201d63771d6

Don't touch errno on success, do set it to EOVERFLOW (the only allowed errno
value according to POSIX: http://pubs.opengroup.org/onlinepubs/9699919799/functions/mktime.html)
on failure.

Bug: http://b/30477946
Change-Id: Ia915c7b9c3bfcd2f9025530cf5b068fe4dd4fd9e

No significant changes other than a default implementation of strftime_l.

Change-Id: I6edd2c03e5e7559f012c0c87d43f7109d641d3ca

POSIX and Java disagree about the sign in a timezone string like "GMT+3".
This means that if you set "persist.sys.timezone" to such a string, native
code and Java code disagree about what time it is. Resolve this by
translating to POSIX form for native code.

Bug: http://b/25463955
Change-Id: I7c08c459dd8514348a12ce419edcbfbfe8f6d327
Test: manually tested with setprop and date.

Bug: http://b/15765976
Change-Id: Ifc8cd19ae621e611d66173ae927ef9a0445965c1

We should fall back to GMT if neither the environment variable nor the
system property is set. This is the case if you wipe a WiFi-only device,
because we currently only take the time zone from cell networks.

Bug: http://b/24773112
Change-Id: I90d236d4d492b6562d75021bd312030b91c1e298

Upstream tzcode said "On platforms with tm_zone, strftime.c now assumes it
is not NULL". Which is fine for any struct tm generated by tzcode, but not
necessarily true of a struct tm constructed by arbitrary code. In particular,
Netflix on Nexus Player was failing to start because they format "%Z" with
a struct tm whose tm_zone is null (the other fields are valid, but, yeah,
that's probably not intentional).

glibc takes a null tm_zone to mean "the current time zone", so let's do that
too. (Historically Android would use the empty string, and POSIX doesn't
clarify which of this is the appropriate behavior when tm_zone is null.)

Bug: http://b/25170306
Change-Id: Idbf68bfe90d143aca7dada8607742905188b1d33

The original comment implied that Android 32 bit was the only one
using a bad time_t, but it turns out 32 bit glibc has the same time_t
as Android. Update the comment to reflect this reality.

Change-Id: I72cdd2c677a6521f7b43d4695a52fd8fdc3305bd

This is quite a large patch because we haven't updated for some time,
but the good news is that upstream is now thread-safe so a lot of our
changes go away in this update and the remaining diff is a lot smaller.

(Note that our whitespace still doesn't match upstream. I use diff -wub
to compare. Upstream doesn't even really have a consistent style. New
code seems to be two spaces, old code tabs.)

From the intervening changelogs (eliding the changes that only affected
the tools, which we don't use):

2014a:
     An uninitialized-storage bug in 'localtime' has been fixed.
     (Thanks to Logan Chien.)

2014b:
     'zic' and 'localtime' no longer reject locations needing four
     transitions per year for the forseeable future.  (Thanks to Andrew
     Main (Zefram).)

2014c:
     <None>

2014d:
     <None>

2014e:
     <None>

2014f:
     'localtime', 'mktime', etc. now use much less stack space if
     ALL_STATE is defined.  (Thanks to Elliott Hughes for reporting the
     problem.)

     Some lint has been removed when using GCC_DEBUG_FLAGS with GCC
     4.9.0.

2014g:
     Unless NETBSD_INSPIRED is defined to 0, the tz library now
     supplies functions for creating and using objects that represent
     time zones. The new functions are tzalloc, tzfree, localtime_rz,
     mktime_z, and (if STD_INSPIRED is also defined) posix2time_z and
     time2posix_z.  They are intended for performance: for example,
     localtime_rz (unlike localtime_r) is trivially thread-safe without
     locking.  (Thanks to Christos Zoulas for proposing NetBSD-inspired
     functions, and to Alan Barrett and Jonathan Lennox for helping to
     debug the change.)

     If THREAD_SAFE is defined to 1, the tz library is now thread-safe.
     Although not needed for tz's own applications, which are single-threaded,
     this supports POSIX better if the tz library is used in multithreaded apps.

     Some crashes have been fixed when zdump or the tz library is given
     invalid or outlandish input.

     The tz library no longer mishandles leap seconds on platforms with
     unsigned time_t in time zones that lack ordinary transitions after 1970.

     The tz code now attempts to infer TM_GMTOFF and TM_ZONE if not
     already defined, to make it easier to configure on common platforms.
     Define NO_TM_GMTOFF and NO_TM_ZONE to suppress this.

     Unless the new macro UNINIT_TRAP is defined to 1, the tz code now
     assumes that reading uninitialized memory yields garbage values
     but does not cause other problems such as traps.

     If TM_GMTOFF is defined and UNINIT_TRAP is 0, mktime is now
     more likely to guess right for ambiguous time stamps near
     transitions where tm_isdst does not change.

     If HAVE_STRFTIME_L is defined to 1, the tz library now defines
     strftime_l for compatibility with recent versions of POSIX.
     Only the C locale is supported, though.  HAVE_STRFTIME_L defaults
     to 1 on recent POSIX versions, and to 0 otherwise.

     tzselect -c now uses a hybrid distance measure that works better
     in Africa.  (Thanks to Alan Barrett for noting the problem.)

     The C source code now ports to NetBSD when GCC_DEBUG_FLAGS is used,
     or when time_tz is defined.

     When HAVE_UTMPX_H is set the 'date' command now builds on systems
     whose <utmpx.h> file does not define WTMPX_FILE, and when setting
     the date it updates the wtmpx file if _PATH_WTMPX is defined.
     This affects GNU/Linux and similar systems.

     For easier maintenance later, some C code has been simplified,
     some lint has been removed, and the code has been tweaked so that
     plain 'make' is more likely to work.

     The C type 'bool' is now used for boolean values, instead of 'int'.

     The long-obsolete LOCALE_HOME code has been removed.

     The long-obsolete 'gtime' function has been removed.

2014h:
     The tz library's localtime and mktime functions now set tzname to a value
     appropriate for the requested time stamp, and zdump now uses this
     on platforms not defining TM_ZONE, fixing a 2014g regression.
     (Thanks to Tim Parenti for reporting the problem.)

     The tz library no longer sets tzname if localtime or mktime fails.

     An access to uninitalized data has been fixed.
     (Thanks to Jörg Richter for reporting the problem.)

     When THREAD_SAFE is defined, the code ports to the C11 memory model.
     A memory leak has been fixed if ALL_STATE and THREAD_SAFE are defined
     and two threads race to initialize data used by gmtime-like functions.
     (Thanks to Andy Heninger for reporting the problems.)

2014i:
     The time-related library functions now set errno on failure,
     and some crashes in the new tzalloc-related library functions
     have been fixed.  (Thanks to Christos Zoulas for reporting
     most of these problems and for suggesting fixes.)

     If USG_COMPAT is defined and the requested time stamp is
     standard time, the tz library's localtime and mktime functions
     now set the extern variable timezone to a value appropriate
     for that time stamp; and similarly for ALTZONE, daylight
     saving time, and the altzone variable.  This change is a
     companion to the tzname change in 2014h, and is designed to
     make timezone and altzone more compatible with tzname.

     The tz library's functions now set errno to EOVERFLOW if they
     fail because the result cannot be represented.  ctime and
     ctime_r now return NULL and set errno when a time stamp is out
     of range, rather than having undefined behavior.

     Some bugs associated with the new 2014g functions have been
     fixed.  This includes a bug that largely incapacitated the new
     functions time2posix_z and posix2time_z.  (Thanks to Christos
     Zoulas.)  It also includes some uses of uninitialized
     variables after tzalloc.  The new code uses the standard type
     'ssize_t', which the Makefile now gives porting advice about.

2014j:
     <None>

2015a:
     tzalloc now scrubs time zone abbreviations compatibly with the way
     that tzset always has, by replacing invalid bytes with '_' and by
     shortening too-long abbreviations.

2015b:
     Fix integer overflow bug in reference 'mktime' implementation.
     (Problem reported by Jörg Richter.)

     Allow -Dtime_tz=time_t compilations, and allow -Dtime_tz=... libraries
     to be used in the same executable as standard-library time_t functions.
     (Problems reported by Bradley White.)

2015c:
     <None>

2015d:
     <None>

2015e:
     <None>

2015f:
     <None>

2015g:
    localtime no longer mishandles America/Anchorage after 2037.
    (Thanks to Bradley White for reporting the bug.)

    On hosts with signed 32-bit time_t, localtime no longer mishandles
    Pacific/Fiji after 2038-01-16 14:00 UTC.

    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.)

Change-Id: I9eb0a8323cb8bd9968fcfe612dc14f45aa3b59d2

logd makes a non-insignificant number of calls to localtime, 3% of
the time in logd is spent performing __system_property_get within the
context of tzset_locked().

Bug: 23685592
Change-Id: I75f8c2d436b60374e92c166b87393abda9487af7

Bug: 24492248

Shifting sign bits left is considered undefined behavior, so we need to
switch these uses to unsigned equivalents. The time_t-related code is
updated relative to upstream sources.

Change-Id: I226e5a929a10f5c57dfcb90c748fdac34eb377c2

Bug: 10637303
Change-Id: I5d525b66cf30d34b421803b876445596bed8d64d

The mktime API returned an uncorrect time when TZ is set as empty.
A timezone UTC/GMT+0 should be implied in the empty case. However
mktime keeps previous information about timezone. If mktime was called
with a timezone which has DST before, the "defaulttype" member of
"state" structure wouldn't be 0. Then it would be used next time,
even though UTC/GMT+0 doesn't have DST.

Added initialization of the "defaulttype" in the empty TZ case.

Change-Id: Ic480c63c548c05444134e0aefb30a7b380e3f40b

(cherry picked from 4c30130a.)

Bug: 18139284
Change-Id: I2670dc1791d635139a5d39a438dc08777439476b

Bug: 18139284
Change-Id: I2670dc1791d635139a5d39a438dc08777439476b

This change should probably be made upstream as well, but they have a
note about not using it because it isn't available on all systems.

Change-Id: I6d8404c031bd2f486532ced55d94bbb4a4cd2e71

The recent libcore ZoneInfo changes mean that we can no longer
compile libcore's ZoneInfo against the RI. Luckily, the field in
our data file that we needed ZoneInfo for isn't actually used.
This change removes our dependence on libcore.

I've left the field in to avoid a file format change. We can remove
the field if/when we next have a real need to bump the file format.

(cherry-pick of 90cb5ffb.)

Bug: 16168653
Change-Id: Iedad2252c2b49f4d8bb2c7d9078b39b622444ca7

The recent libcore ZoneInfo changes mean that we can no longer
compile libcore's ZoneInfo against the RI. Luckily, the field in
our data file that we needed ZoneInfo for isn't actually used.
This change removes our dependence on libcore.

I've left the field in to avoid a file format change. We can remove
the field if/when we next have a real need to bump the file format.

Bug: 16168653
Change-Id: Iedad2252c2b49f4d8bb2c7d9078b39b622444ca7

This also brings our copy of strftime.c much closer to upstream, though
we still have several GNU extensions and hacks to deal with Android32's
broken time_t.

Bug: 15765976

(cherry picked from commit 39d903ae)

Change-Id: Ie278d3e976b7adc77bad5ce795dd4899cfbf3648

Bug: 15765976

(cherry picked from commit 905e6d58)

Change-Id: Ic7435308e8b521886f42ac7bf59531924921ea67

Bug: 15765976
Change-Id: Ibd9cf07067ec8dffe9fda6c3d498d4ab90708220

This also brings our copy of strftime.c much closer to upstream, though
we still have several GNU extensions and hacks to deal with Android32's
broken time_t.

Bug: 15765976
Change-Id: Ic9ef36e8acd3619504ecc4d73feec2b61fd4dfa1

Bug: 11156955
Change-Id: Ib98d837b56cbbdfd01687cb3054fe3103eec0da9

I'm sick of having so many different compilers.

Change-Id: I9088c38df2504e2b827d0ce5ba0fa551ae48f8f9

Parts of this are just getting us in sync with upstream, but the
'const' stuff is our own mess. We should kill the *_tz functions
and lose this difference from upstream.

Change-Id: I17d26534ed3f54667143d78147a8c53be56d7b33

This brings us closer to upstream's ToT localtime.c; our main interest
being their alternative fix for the stack usage we addressed in commit
8a8b0c9b.

Bug: 14468519
Change-Id: Ic28600115afda7f3158d91255edf422678bac082

There's one left, but that's not fixed upstream yet.

Change-Id: Iba920cb7b156357c7f5e8220eb55ff1637ff48a1

This structure is huge (~18000 bytes on arm64) and can blow out
the stack very easily.
Modify the code to allocate these structures instead of leaving them
on the stack.

Bug: 14468519
Change-Id: I774f71235d896d32a14ab1af06f95ca9ef819f52

That's what the Google style guide recommends, and we're starting
to get a mix.

Change-Id: Ib0c53a890bb5deed5c679e887541a715faea91fc

I've reported the wcsftime bug upstream, but we really just want to use -D
to ensure the buggy code isn't built. (I've also brought our strftime a bit
closer to upstream now we have the right define.)

I don't think upstream is likely to fix all their sign-compare and
uninitialized warnings, so let's just silence them.

As for libm, again upstream isn't likely to fix all their warnings, and
silencing those made the ones that were our fault stand out. I've fixed
our <math.h> to fix the warnings caused by our lack of definitions for
the non-imprecise long-double functions. I checked the C99 standard, and
all these functions are there.

Change-Id: Iee8e1182c1db375058fb2c451eceb212bab47a37

We need a workaround in strftime as long as we still need to support
64-bit times on LP32.

Change-Id: I8ffb616f6312d4063fb9ea3c36b52653e8f4c5f8

Bug: 14313703
Bug: https://code.google.com/p/android/issues/detail?id=61130
Change-Id: Id9b240fce20d4a6f2660792070e02b2b5f287655

Bug: 12246757
Change-Id: I8186e75f4899161af48cbf66e8f907dac0a326a2

Bug: 12246757
Change-Id: I3d5d2318155b1f54ef80afd58b1e5ca9a6d7018e

This costs us about 1000 fewer syscalls, which makes "adb shell strace date"
a lot more readable (which is the reason I've been meaning to fix this for a
long time now), but also actually saves a measurable amount of time.

Longer-term we should try to keep the tzdata mmap(2)ed in like libcore
does.

Change-Id: I1dd9c81968a13d3a6a55ba17f8a7d5c1f38cd103

Change-Id: Ib5d9aaa7a618e478ce8e5e82f967cf535bb1a5a3

The x86_64 build was failing because clone.S had a call to __thread_entry which
was being added to a different intermediate .a on the way to making libc.so,
and the linker couldn't guarantee statically that such a relocation would be
possible.

  ld: error: out/target/product/generic_x86_64/obj/STATIC_LIBRARIES/libc_common_intermediates/libc_common.a(clone.o): requires dynamic R_X86_64_PC32 reloc against '__thread_entry' which may overflow at runtime; recompile with -fPIC

This patch addresses that by ensuring that the caller and callee end up in the
same intermediate .a. While I'm here, I've tried to clean up some of the mess
that led to this situation too. In particular, this removes libc/private/ from
the default include path (except for the DNS code), and splits out the DNS
code into its own library (since it's a weird special case of upstream NetBSD
code that's diverged so heavily it's unlikely ever to get back in sync).

There's more cleanup of the DNS situation possible, but this is definitely a
step in the right direction, and it's more than enough to get x86_64 building
cleanly.

Change-Id: I00425a7245b7a2573df16cc38798187d0729e7c4

  libc/tzcode/localtime.c: In function 'differ_by_repeat':
  libc/tzcode/localtime.c:338:2: error: comparison is always false due to limited range of data type [-Werror=type-limits]

Change-Id: Ic84be6391a66e9d50ed98f41d865387c77a60ffa