From 957e238614326198452b53498ae98e546fce7366 Mon Sep 17 00:00:00 2001 From: Denys Vlasenko Date: Sat, 9 Jan 2010 21:58:50 +0100 Subject: ctime: do not use static struct tm buffer text data bss dec hex filename - 19 0 0 19 13 libc/misc/time/ctime.o + 25 0 0 25 19 libc/misc/time/ctime.o Signed-off-by: Denys Vlasenko --- libc/misc/time/time.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) (limited to 'libc/misc') diff --git a/libc/misc/time/time.c b/libc/misc/time/time.c index 583c17aad..dfa8c0daf 100644 --- a/libc/misc/time/time.c +++ b/libc/misc/time/time.c @@ -274,7 +274,7 @@ libc_hidden_def(asctime) * If we take the implicit assumption as given, then the implementation below * is still incorrect for tm_year values < -900, as there will be either * 0-padding and/or a missing negative sign for the year conversion . But given - * the ususal use of asctime(), I think it isn't unreasonable to restrict correct + * the usual use of asctime(), I think it isn't unreasonable to restrict correct * operation to the domain of years between 1000 and 9999. */ @@ -465,8 +465,22 @@ clock_t clock(void) char *ctime(const time_t *t) { - /* ANSI/ISO/SUSv3 say that ctime is equivalent to the following. */ - return asctime(localtime(t)); + /* ANSI/ISO/SUSv3 say that ctime is equivalent to the following: + * return asctime(localtime(t)); + * I don't think "equivalent" means "it uses the same internal buffer", + * it means "gives the same resultant string". + * + * I doubt anyone ever uses weird code like: + * struct tm *ptm = localtime(t1); ...; ctime(t2); use(ptm); + * which relies on the assumption that ctime's and localtime's + * internal static struct tm is the same. + * + * Using localtime_r instead of localtime avoids linking in + * localtime's static buffer: + */ + struct tm xtm; + + return asctime(localtime_r(t, &xtm)); } libc_hidden_def(ctime) #endif -- cgit v1.2.3