Changes affecting future time stamps
Egypt's spring-forward transition is at 24:00 on April's last Thursday,
not 00:00 on April's last Friday. 2015's transition will therefore be on
Thursday, April 30 at 24:00, not Friday, April 24 at 00:00. Similar fixes
apply to 2026, 2037, 2043, etc. (Thanks to Steffen Thorsen.)
Changes affecting past time stamps
The following changes affect some pre-1991 Chile-related time stamps
in America/Santiago, Antarctica/Palmer, and Pacific/Easter.
The 1910 transition was January 10, not January 1.
The 1918 transition was September 10, not September 1.
The UTC-4 time observed from 1932 to 1942 is now considered to be
standard time, not year-round DST.
Santiago observed DST (UTC-3) from 1946-07-15 through 1946-08-31,
then reverted to standard time, then switched its time zone to
UTC-5 on 1947-04-01.
Assume transitions before 1968 were at 00:00, since we have no data
saying otherwise.
The spring 1988 transition was 1988-10-09, not 1988-10-02.
The fall 1990 transition was 1990-03-11, not 1990-03-18.
Assume no UTC offset change for Pacific/Easter on 1890-01-01,
and omit all transitions on Pacific/Easter from 1942 through 1946
since we have no data suggesting that they existed.
One more zone has been turned into a link, as it differed
from an existing zone only for older time stamps. As usual,
this change affects UTC offsets in pre-1970 time stamps only.
The zone's old contents have been moved to the 'backzone' file.
The affected zone is America/Montreal.
Bug: 20287125
(cherry-picked from commit d2177404e2)
Change-Id: I55224cc63b314a8e4c2f1c83f8bc4921316c8e4d
Having p_align > page_size leads to the situation when striping
packed executables results in unnecessary p_vaddr adjustments.
And it also may result (with probability 1 - 1/sizeof(uintptr_t)) in
misaligned segments following .dynstr
Bug: http://b/20629834
Bug: http://b/18051137
(cherry picked from commit b293969c6d)
Change-Id: I2fb15cf5cb52fada6511d5af93df099fc2cbf7ba
Spencer Low points out that we never actually set a name because the constant
part of the string was longer than the kernel's maximum, and the kernel
rejects long names rather than truncate.
Shorten the fixed part of the string while still keeping it meaningful. 9999
POSIX timers should be enough for any process...
Bug: https://code.google.com/p/android/issues/detail?id=170089
Change-Id: Ic05f07584c1eac160743519091a540ebbf8d7eb1
The visibility control in pthread_atfork.h is incorrect.
It breaks 64bit libc.so by hiding pthread_atfork.
This reverts commit 6df122f852.
Change-Id: I21e4b344d500c6f6de0ccb7420b916c4e233dd34
This doesn't affect code like Chrome that correctly ignores EINTR on
close, makes code that tries TEMP_FAILURE_RETRY work (where before it might
have closed a different fd and appeared to succeed, or had a bogus EBADF),
and makes "goto fail" code work (instead of mistakenly assuming that EINTR
means that the close failed).
Who loses? Anyone actively trying to detect that they caught a signal while
in close(2). I don't think those people exist, and I think they have better
alternatives available.
Bug: https://code.google.com/p/chromium/issues/detail?id=269623
Bug: http://b/20501816
Change-Id: I11e2f66532fe5d1b0082b2433212e24bdda8219b
