Message ID | 20180926073053.11710-2-albert.aribaud@3adev.fr |
---|---|
State | New |
Headers | show |
Series | [v8,1/2] Y2038: Add 64-bit time for all architectures | expand |
On Wed, 26 Sep 2018, Albert ARIBAUD (3ADEV) wrote: > Now that __time_64_t exists, we can switch internal function > __tz_convert from 32-bit to 64-bit time. This involves switching > some other internal functions and turning some implementations > which use these into wrappers between public 32-bit and internal > 64-bit time. You're missing the information about what platforms this patch was tested on with the full glibc testsuite. That's critical information for such a patch submission, which needs testing on both 32-bit and 64-bit platforms. (Later patches supporting using new syscalls will need testing on additional configurations, including building with old kernel headers; building with kernel headers with the new syscalls but running on a kernel without them; and building with new kernel headers and running on a kernel with the new syscalls.)
Hi Joseph, On Wed, 26 Sep 2018 16:14:06 +0000, Joseph Myers <joseph@codesourcery.com> wrote : > On Wed, 26 Sep 2018, Albert ARIBAUD (3ADEV) wrote: > > > Now that __time_64_t exists, we can switch internal function > > __tz_convert from 32-bit to 64-bit time. This involves switching > > some other internal functions and turning some implementations > > which use these into wrappers between public 32-bit and internal > > 64-bit time. > > You're missing the information about what platforms this patch was tested > on with the full glibc testsuite. That's critical information for such a > patch submission, which needs testing on both 32-bit and 64-bit platforms. > (Later patches supporting using new syscalls will need testing on > additional configurations, including building with old kernel headers; > building with kernel headers with the new syscalls but running on a kernel > without them; and building with new kernel headers and running on a kernel > with the new syscalls.) I've started with the simplest case for me, a native x86_64 test on a Xubuntu 18.04 machine with gcc 7.3.0. This is how I did it: $ cd /home/3adev/glibc/build $ /home/3dev/glibc/src/configure --prefix /home/3adev/glibc/local $ make -j3 $ make -j3 check Running this with /home/3dev/glibc/{build,local} empty, and /home/3dev/glibc/src being a checkout of tag glibc-2.28, that is, without any patches of mine. I end up with > [...] > Summary of test results: > 132 FAIL > 5788 PASS > 11 UNSUPPORTED > 17 XFAIL > 2 XPASS > Makefile:345: recipe for target 'tests' failed > make[1]: *** [tests] Error 1 > make[1] : on quitte le répertoire « /home/3adev/glibc/src » > Makefile:9: recipe for target 'check' failed > make: *** [check] Error 2 Is it normal that the make check fail with a non-zero number of FAIL and XFAIL? If it is not a normal result, then what could possibly cause it considering I am building the official glibc 2.28? Is it is a normal result (i.e. this release of glibc is known to FAIL and XFAIL this way for x86_64), then where can I find the expected FAIL and XFAIL details for a given architecture and a given release of glibc? Cordialement, Albert ARIBAUD 3ADEV
On Sat, 29 Sep 2018, Albert ARIBAUD wrote: > > [...] > > Summary of test results: > > 132 FAIL > > 5788 PASS > > 11 UNSUPPORTED > > 17 XFAIL > > 2 XPASS > > Makefile:345: recipe for target 'tests' failed > > make[1]: *** [tests] Error 1 > > make[1] : on quitte le répertoire « /home/3adev/glibc/src » > > Makefile:9: recipe for target 'check' failed > > make: *** [check] Error 2 > > Is it normal that the make check fail with a non-zero number of FAIL and > XFAIL? You should expect XFAILs (for example, for conform/ tests that deliberately test features of the relevant standard that are either not provided by glibc, or are deliberately unsupported). You should not expect anything like 132 FAILs; you'll need to get a working configuration for testing without so many FAILs on unmodified sources before you can effectively test proposed patches. > Is it is a normal result (i.e. this release of glibc is known to FAIL > and XFAIL this way for x86_64), then where can I find the expected FAIL > and XFAIL details for a given architecture and a given release of glibc? See the per-release wiki pages, e.g. <https://sourceware.org/glibc/wiki/Release/2.28>. That shows 17 XFAILs as expected for x86_64, but no FAILs. (Ignore the results for WSL - the Windows subsystem for Linux emulation - all they show is defects in that subsystem, it's not a suitable environment for normal glibc testing.) On Ubuntu 18.04 (using a locally built compiler - if you do that, note you need to copy libgcc_s.so.* and libstdc++.so.* into the build directory before running the tests) I get two FAILs: FAIL: resolv/tst-resolv-ai_idn FAIL: resolv/tst-resolv-ai_idn-latin1 Those appear in the architecture-independent section of the wiki page, for systems with too-old libidn2. For 32-bit testing on 64-bit Ubuntu 18.04 (again, with a locally built compiler) I get one FAIL: FAIL: nss/tst-nss-test3
Hi Joseph, Le Sun, 30 Sep 2018 13:37:58 +0000, Joseph Myers <joseph@codesourcery.com> a écrit : > On Sat, 29 Sep 2018, Albert ARIBAUD wrote: > > > > [...] > > > Summary of test results: > > > 132 FAIL > > > 5788 PASS > > > 11 UNSUPPORTED > > > 17 XFAIL > > > 2 XPASS > > > Makefile:345: recipe for target 'tests' failed > > > make[1]: *** [tests] Error 1 > > > make[1] : on quitte le répertoire « /home/3adev/glibc/src » > > > Makefile:9: recipe for target 'check' failed > > > make: *** [check] Error 2 > > > > Is it normal that the make check fail with a non-zero number of FAIL and > > XFAIL? > > You should expect XFAILs (for example, for conform/ tests that > deliberately test features of the relevant standard that are either not > provided by glibc, or are deliberately unsupported). > > You should not expect anything like 132 FAILs; you'll need to get a > working configuration for testing without so many FAILs on unmodified > sources before you can effectively test proposed patches. > > > Is it is a normal result (i.e. this release of glibc is known to FAIL > > and XFAIL this way for x86_64), then where can I find the expected FAIL > > and XFAIL details for a given architecture and a given release of glibc? > > See the per-release wiki pages, e.g. > <https://sourceware.org/glibc/wiki/Release/2.28>. That shows 17 XFAILs as > expected for x86_64, but no FAILs. (Ignore the results for WSL - the > Windows subsystem for Linux emulation - all they show is defects in that > subsystem, it's not a suitable environment for normal glibc testing.) > > On Ubuntu 18.04 (using a locally built compiler - if you do that, note you > need to copy libgcc_s.so.* and libstdc++.so.* into the build directory > before running the tests) I get two FAILs: > > FAIL: resolv/tst-resolv-ai_idn > FAIL: resolv/tst-resolv-ai_idn-latin1 > > Those appear in the architecture-independent section of the wiki page, for > systems with too-old libidn2. > > For 32-bit testing on 64-bit Ubuntu 18.04 (again, with a locally built > compiler) I get one FAIL: > > FAIL: nss/tst-nss-test3 I'd run make check in the past without these errors, hence my surprise. Apparently, the issue lies with the value of --prefix at configure time; It was not /usr, whereas if it is, and on a X86_64 machine, I do: mkdir temp cd temp git clone git://sourceware.org/git/glibc.git src cd src git checkout origin/release/2.28/master cd .. mkdir build cd build ./configure --prefix=/usr make make check I end up with UNSUPPORTED: elf/tst-audit10 UNSUPPORTED: elf/tst-avx512 XPASS: elf/tst-protected1a XPASS: elf/tst-protected1b UNSUPPORTED: math/test-double-libmvec-alias-avx512 UNSUPPORTED: math/test-double-libmvec-alias-avx512-main UNSUPPORTED: math/test-double-libmvec-sincos-avx512 UNSUPPORTED: math/test-float-libmvec-alias-avx512 UNSUPPORTED: math/test-float-libmvec-alias-avx512-main UNSUPPORTED: math/test-float-libmvec-sincosf-avx512 UNSUPPORTED: misc/tst-pkey FAIL: resolv/tst-resolv-ai_idn FAIL: resolv/tst-resolv-ai_idn-latin1 Summary of test results: 2 FAIL 5924 PASS 9 UNSUPPORTED 17 XFAIL 2 XPASS Which I assume is fine, as the two FAILs are the libidn2 ones. I take this result as a reference and am running make check now on patches applied above release/2.28/master; If the results are the same as the reference, I'll consider the patches good for resubmission. Cordialement, Albert ARIBAUD 3ADEV
On Thu, 4 Oct 2018, Albert ARIBAUD wrote: > Which I assume is fine, as the two FAILs are the libidn2 ones. Yes, those results are fine. > I take this result as a reference and am running make check now on > patches applied above release/2.28/master; If the results are the > same as the reference, I'll consider the patches good for resubmission. Note that you should test for a 32-bit configuration as well - this applies to pretty much all the patches for 64-bit time, they need testing for both 32-bit and 64-bit configurations (some will need other testing, e.g. with kernels with the Y2038 patches included, but that doesn't apply to this one). It should be possible to test natively for 32-bit on a 64-bit system if you install the relevant OS packages for 32-bit libraries (including development packages), and specify CC="gcc -m32" CXX="g++ -m32" when configuring for i686-pc-linux-gnu, but I haven't tried that using OS compiler packages (I test natively for 32-bit on a 64-bit system, but using locally built compilers).
Hi Joseph, Le Thu, 4 Oct 2018 12:14:46 +0000, Joseph Myers <joseph@codesourcery.com> a écrit : > On Thu, 4 Oct 2018, Albert ARIBAUD wrote: > > > Which I assume is fine, as the two FAILs are the libidn2 ones. > > Yes, those results are fine. Ok. > > I take this result as a reference and am running make check now on > > patches applied above release/2.28/master; If the results are the > > same as the reference, I'll consider the patches good for resubmission. > > Note that you should test for a 32-bit configuration as well - this > applies to pretty much all the patches for 64-bit time, they need testing > for both 32-bit and 64-bit configurations (some will need other testing, > e.g. with kernels with the Y2038 patches included, but that doesn't apply > to this one). > > It should be possible to test natively for 32-bit on a 64-bit system if > you install the relevant OS packages for 32-bit libraries (including > development packages), and specify CC="gcc -m32" CXX="g++ -m32" when > configuring for i686-pc-linux-gnu, but I haven't tried that using OS > compiler packages (I test natively for 32-bit on a 64-bit system, but > using locally built compilers). I'll launch a test once the current jobs have finished running, however I've got a physical 32-bit ARM system with a Debian Stretch distro, so I'll most certainly go the simpler native route for now, at least until I get to test on on really many systems, at which point I'll include the "32-bit on 64-bit" case too. Cordialement, Albert ARIBAUD 3ADEV
Hi Albert, On Thu, 4 Oct 2018 15:40:52 +0200, Albert ARIBAUD <albert.aribaud@3adev.fr> wrote : > Hi Joseph, > > Le Thu, 4 Oct 2018 12:14:46 +0000, Joseph Myers > <joseph@codesourcery.com> a écrit : > > > On Thu, 4 Oct 2018, Albert ARIBAUD wrote: > > > > > Which I assume is fine, as the two FAILs are the libidn2 ones. > > > > Yes, those results are fine. > > Ok. BTW, one quick question re the summary shown at the end of a make check. Here I get Summary of test results: 2 FAIL 5924 PASS 9 UNSUPPORTED 17 XFAIL 2 XPASS I assumed that for each category (FAIL, PASS, UNSUPPORTED, XFAIL, XPASS) the number before it was equal to the number of files named "*.test-result" whose content started with said category, so for instance if I ran the command: find . -name "*.test-result" -exec grep ^FAIL: {} \; | wc -l The output would be 2, because there are 2 FAIL results. While the summary and grep agree for FAIL (2), UNSUPPORTED (9), XFAIL (17) and XPASS (2), they disagree on PASS: the results say 5924, the grep says 6018. Also, the total number of files named "*.test-result" is 6048, which equals 6018 + 2 + 9 +17 + 2 -- in other words, it is as if some actual "PASS" test results were not counted in the summary. Could anyone explain to me why the summary PASS count and the actual PASS result file count disagree? Cordialement, Albert ARIBAUD 3ADEV
On Thu, 4 Oct 2018, Albert ARIBAUD wrote: > Could anyone explain to me why the summary PASS count and the actual > PASS result file count disagree? The rules for generating some files used in the testsuite generate the .test-result files; those files are not listed in tests-special as being tests, but some other similar files, using the same makefile rules, are so listed, hence the files being generated. It's the settings of tests and tests-special in each subdirectory that determine what counts as a test for the purposes of the summaries. (I think the files in question probably *should* be listed in tests-special.)
diff --git a/include/time.h b/include/time.h index e99711a556..7dbd4dce22 100644 --- a/include/time.h +++ b/include/time.h @@ -46,7 +46,7 @@ extern void __tzfile_default (const char *std, const char *dst, long int stdoff, long int dstoff) attribute_hidden; extern void __tzset_parse_tz (const char *tz) attribute_hidden; -extern void __tz_compute (time_t timer, struct tm *tm, int use_localtime) +extern void __tz_compute (__time64_t timer, struct tm *tm, int use_localtime) __THROW attribute_hidden; /* Subroutine of `mktime'. Return the `time_t' representation of TP and @@ -56,18 +56,47 @@ extern time_t __mktime_internal (struct tm *__tp, struct tm *(*__func) (const time_t *, struct tm *), long int *__offset) attribute_hidden; + +/* nis/nis_print.c needs ctime, so even if ctime is not declared here, + we define __ctime64 as ctime so that nis/nis_print.c can get linked + against a function called ctime. */ +#if __TIMESIZE == 64 +# define __ctime64 ctime +#endif + +#if __TIMESIZE == 64 +# define __localtime64 localtime +#else +extern struct tm *__localtime64 (const __time64_t *__timer); +#endif + extern struct tm *__localtime_r (const time_t *__timer, struct tm *__tp) attribute_hidden; +#if __TIMESIZE == 64 +# define __localtime64_r __localtime_r +#else +extern struct tm *__localtime64_r (const __time64_t *__timer, + struct tm *__tp) attribute_hidden; +#endif + extern struct tm *__gmtime_r (const time_t *__restrict __timer, struct tm *__restrict __tp); libc_hidden_proto (__gmtime_r) -/* Compute the `struct tm' representation of *T, +#if __TIMESIZE == 64 +# define __gmtime64 gmtime +# define __gmtime64_r __gmtime_r +#else +extern struct tm *__gmtime64_r (const __time64_t *__restrict __timer, + struct tm *__restrict __tp); +#endif + +/* Compute the `struct tm' representation of T, offset OFFSET seconds east of UTC, and store year, yday, mon, mday, wday, hour, min, sec into *TP. Return nonzero if successful. */ -extern int __offtime (const time_t *__timer, +extern int __offtime (__time64_t __timer, long int __offset, struct tm *__tp) attribute_hidden; @@ -76,8 +105,8 @@ extern char *__asctime_r (const struct tm *__tp, char *__buf) extern void __tzset (void) attribute_hidden; /* Prototype for the internal function to get information based on TZ. */ -extern struct tm *__tz_convert (const time_t *timer, int use_localtime, - struct tm *tp) attribute_hidden; +extern struct tm *__tz_convert (__time64_t timer, int use_localtime, + struct tm *tp) attribute_hidden; extern int __nanosleep (const struct timespec *__requested_time, struct timespec *__remaining); diff --git a/time/ctime.c b/time/ctime.c index 1222614f29..286c6b579c 100644 --- a/time/ctime.c +++ b/time/ctime.c @@ -20,9 +20,22 @@ /* Return a string as returned by asctime which is the representation of *T in that form. */ char * -ctime (const time_t *t) +__ctime64 (const __time64_t *t) { /* The C Standard says ctime (t) is equivalent to asctime (localtime (t)). In particular, ctime and asctime must yield the same pointer. */ - return asctime (localtime (t)); + return asctime (__localtime64 (t)); } + +/* Provide a 32-bit wrapper if needed */ + +#if __TIMESIZE != 64 + +char * +ctime (const time_t *t) +{ + __time64_t t64 = *t; + return __ctime64 (&t64); +} + +#endif diff --git a/time/ctime_r.c b/time/ctime_r.c index c111146d76..84089599a7 100644 --- a/time/ctime_r.c +++ b/time/ctime_r.c @@ -22,8 +22,21 @@ /* Return a string as returned by asctime which is the representation of *T in that form. Reentrant version. */ char * -ctime_r (const time_t *t, char *buf) +__ctime64_r (const __time64_t *t, char *buf) { struct tm tm; - return __asctime_r (__localtime_r (t, &tm), buf); + return __asctime_r (__localtime64_r (t, &tm), buf); } + +/* Provide a 32-bit wrapper if needed */ + +#if __TIMESIZE != 64 + +char * +ctime_r (const time_t *t, char *buf) +{ + __time64_t t64 = *t; + return __ctime64_r (&t64, buf); +} + +#endif diff --git a/time/gmtime.c b/time/gmtime.c index dc33b3e68a..d485a38c6f 100644 --- a/time/gmtime.c +++ b/time/gmtime.c @@ -18,20 +18,49 @@ #include <time.h> -/* Return the `struct tm' representation of *T in UTC, +/* Return the `struct tm' representation of T in UTC, using *TP to store the result. */ +struct tm * +__gmtime64_r (const __time64_t *t, struct tm *tp) +{ + return __tz_convert (*t, 0, tp); +} + +/* Provide a 32-bit wrapper if needed */ + +#if __TIMESIZE != 64 + struct tm * __gmtime_r (const time_t *t, struct tm *tp) { - return __tz_convert (t, 0, tp); + __time64_t t64 = *t; + return __gmtime64_r (&t64, tp); } + +#endif + +/* This always works because either __TIMESIZE != 64 and __gmtime_r exists + or __TIMESIZE == 64 and the definition of __gmtime64_r above actually + defined __gmtime_r. */ libc_hidden_def (__gmtime_r) weak_alias (__gmtime_r, gmtime_r) +/* Return the `struct tm' representation of 64-bit-time *T in UTC. */ +struct tm * +__gmtime64 (const __time64_t *t) +{ + return __tz_convert (*t, 0, &_tmbuf); +} + +/* Provide a 32-bit wrapper if needed */ + +#if __TIMESIZE != 64 -/* Return the `struct tm' representation of *T in UTC. */ struct tm * gmtime (const time_t *t) { - return __tz_convert (t, 0, &_tmbuf); + __time64_t t64 = *t; + return __gmtime64 (&t64); } + +#endif diff --git a/time/localtime.c b/time/localtime.c index 8684a8a971..e36d6ccaca 100644 --- a/time/localtime.c +++ b/time/localtime.c @@ -21,21 +21,49 @@ /* The C Standard says that localtime and gmtime return the same pointer. */ struct tm _tmbuf; - /* Return the `struct tm' representation of *T in local time, using *TP to store the result. */ +struct tm * +__localtime64_r (const __time64_t *t, struct tm *tp) +{ + return __tz_convert (*t, 1, tp); +} + +/* Provide a 32-bit wrapper if needed */ + +#if __TIMESIZE != 64 + struct tm * __localtime_r (const time_t *t, struct tm *tp) { - return __tz_convert (t, 1, tp); + __time64_t t64 = *t; + return __localtime64_r (&t64, tp); } -weak_alias (__localtime_r, localtime_r) +#endif + +/* This always works because either __TIMESIZE != 64 and __localtime_r + exists or __TIMESIZE == 64 and the definition of __localtime64_r above + actually defined __localtime_r. */ +weak_alias (__localtime_r, localtime_r) /* Return the `struct tm' representation of *T in local time. */ +struct tm * +__localtime64 (const __time64_t *t) +{ + return __tz_convert (*t, 1, &_tmbuf); +} + +/* Provide a 32-bit wrapper if needed */ + +#if __TIMESIZE != 64 + struct tm * localtime (const time_t *t) { - return __tz_convert (t, 1, &_tmbuf); + __time64_t t64 = *t; + return __localtime64 (&t64); } libc_hidden_def (localtime) + +#endif diff --git a/time/offtime.c b/time/offtime.c index 04c48389fc..3309fcd484 100644 --- a/time/offtime.c +++ b/time/offtime.c @@ -21,18 +21,18 @@ #define SECS_PER_HOUR (60 * 60) #define SECS_PER_DAY (SECS_PER_HOUR * 24) -/* Compute the `struct tm' representation of *T, +/* Compute the `struct tm' representation of T, offset OFFSET seconds east of UTC, and store year, yday, mon, mday, wday, hour, min, sec into *TP. Return nonzero if successful. */ int -__offtime (const time_t *t, long int offset, struct tm *tp) +__offtime (__time64_t t, long int offset, struct tm *tp) { - time_t days, rem, y; + __time64_t days, rem, y; const unsigned short int *ip; - days = *t / SECS_PER_DAY; - rem = *t % SECS_PER_DAY; + days = t / SECS_PER_DAY; + rem = t % SECS_PER_DAY; rem += offset; while (rem < 0) { @@ -60,7 +60,7 @@ __offtime (const time_t *t, long int offset, struct tm *tp) while (days < 0 || days >= (__isleap (y) ? 366 : 365)) { /* Guess a corrected year, assuming 365 days per year. */ - time_t yg = y + days / 365 - (days % 365 < 0); + __time64_t yg = y + days / 365 - (days % 365 < 0); /* Adjust DAYS and Y to match the guessed year. */ days -= ((yg - y) * 365 diff --git a/time/tzfile.c b/time/tzfile.c index 844a68de8c..3920525bf3 100644 --- a/time/tzfile.c +++ b/time/tzfile.c @@ -633,16 +633,10 @@ __tzfile_compute (__time64_t timer, int use_localtime, /* Convert to broken down structure. If this fails do not use the string. */ - { - time_t truncated = timer; - if (__glibc_unlikely (truncated != timer - || ! __offtime (&truncated, 0, tp))) - goto use_last; - } - - /* Use the rules from the TZ string to compute the change. - timer fits into time_t due to the truncation check - above. */ + if (__glibc_unlikely (! __offtime (timer, 0, tp))) + goto use_last; + + /* Use the rules from the TZ string to compute the change. */ __tz_compute (timer, tp, 1); /* If tzspec comes from posixrules loaded by __tzfile_default, diff --git a/time/tzset.c b/time/tzset.c index a828b9fb75..834cc3ccec 100644 --- a/time/tzset.c +++ b/time/tzset.c @@ -16,7 +16,6 @@ <http://www.gnu.org/licenses/>. */ #include <ctype.h> -#include <errno.h> #include <libc-lock.h> #include <stdbool.h> #include <stddef.h> @@ -27,7 +26,7 @@ #include <timezone/tzfile.h> -#define SECSPERDAY ((time_t) 86400) +#define SECSPERDAY ((__time64_t) 86400) char *__tzname[2] = { (char *) "GMT", (char *) "GMT" }; int __daylight = 0; @@ -55,7 +54,7 @@ typedef struct /* We cache the computed time of change for a given year so we don't have to recompute it. */ - time_t change; /* When to change to this zone. */ + __time64_t change; /* When to change to this zone. */ int computed_for; /* Year above is computed for. */ } tz_rule; @@ -416,7 +415,7 @@ tzset_internal (int always) tz_rules[0].name = tz_rules[1].name = "UTC"; if (J0 != 0) tz_rules[0].type = tz_rules[1].type = J0; - tz_rules[0].change = tz_rules[1].change = (time_t) -1; + tz_rules[0].change = tz_rules[1].change = -1; update_vars (); return; } @@ -424,13 +423,13 @@ tzset_internal (int always) __tzset_parse_tz (tz); } -/* Figure out the exact time (as a time_t) in YEAR +/* Figure out the exact time (as a __time64_t) in YEAR when the change described by RULE will occur and put it in RULE->change, saving YEAR in RULE->computed_for. */ static void compute_change (tz_rule *rule, int year) { - time_t t; + __time64_t t; if (year != -1 && rule->computed_for == year) /* Operations on times in 2 BC will be slower. Oh well. */ @@ -516,7 +515,7 @@ compute_change (tz_rule *rule, int year) /* Figure out the correct timezone for TM and set `__tzname', `__timezone', and `__daylight' accordingly. */ void -__tz_compute (time_t timer, struct tm *tm, int use_localtime) +__tz_compute (__time64_t timer, struct tm *tm, int use_localtime) { compute_change (&tz_rules[0], 1900 + tm->tm_year); compute_change (&tz_rules[1], 1900 + tm->tm_year); @@ -562,20 +561,14 @@ __tzset (void) } weak_alias (__tzset, tzset) -/* Return the `struct tm' representation of *TIMER in the local timezone. +/* Return the `struct tm' representation of TIMER in the local timezone. Use local time if USE_LOCALTIME is nonzero, UTC otherwise. */ struct tm * -__tz_convert (const time_t *timer, int use_localtime, struct tm *tp) +__tz_convert (__time64_t timer, int use_localtime, struct tm *tp) { long int leap_correction; int leap_extra_secs; - if (timer == NULL) - { - __set_errno (EINVAL); - return NULL; - } - __libc_lock_lock (tzset_lock); /* Update internal database according to current TZ setting. @@ -584,14 +577,14 @@ __tz_convert (const time_t *timer, int use_localtime, struct tm *tp) tzset_internal (tp == &_tmbuf && use_localtime); if (__use_tzfile) - __tzfile_compute (*timer, use_localtime, &leap_correction, + __tzfile_compute (timer, use_localtime, &leap_correction, &leap_extra_secs, tp); else { if (! __offtime (timer, 0, tp)) tp = NULL; else - __tz_compute (*timer, tp, use_localtime); + __tz_compute (timer, tp, use_localtime); leap_correction = 0L; leap_extra_secs = 0; }