From 5672e77d3102a990a2aa11e7e56ebfe6a0eee369 Mon Sep 17 00:00:00 2001 From: "Kaleb S. KEITHLEY" Date: Wed, 13 Jun 2012 09:13:04 -0400 Subject: localtime and ctime are not MT-SAFE There are a number of nit-level issues throughout the source with the use of localtime and ctime. While they apparently aren't causing too many problems, apart from the one in bz 828058, they ought to be fixed. Among the "real" problems that are fixed in this patch: 1) general localtime and ctime not MT-SAFE. There's a non-zero chance that another thread calling localtime (or ctime) will over-write the static data about to be used in another thread 2) localtime(& <64-bit-type>) or ctime(& <64-bit-type>) generally not a problem on 64-bit or little-endian 32-bit. But even though we probably have zero users on big-ending 32-bit platforms, it's still incorrect. 3) multiple nested calls passed as params. Last one wins, i.e. over- writes result of prior calls. 4) Inconsistent error handling. Most of these calls are for logging, tracing, or dumping. I submit that if an error somehow occurs in the call to localtime or ctime, the log/trace/dump still should still occur. 5) Appliances should all have their clocks set to UTC, and all log entries, traces, and dumps should use GMT. 6) fix strtok(), change to strtok_r() Other things this patch fixes/changes (that aren't bugs per se): 1) Change "%Y-%m-%d %H:%M:%S" and similar to their equivalent shorthand, e.g. "%F %T" 2) change sizeof(timestr) to sizeof timestr. sizeof is an operator, not a function. You don't use i +(32), why use sizeof(). (And yes, you do use parens with sizeof().) 3) change 'char timestr[256]' to 'char timestr[32]' where appropriate. Per-thread stack is limited. Time strings are never longer than ~20 characters, so why waste 220+ bytes on the stack? Things this patch doesn't fix: 1) hodgepodge of %Y-%m-%d %H:%M:%S versus %Y/%m/%d-%H%M%S and other variations. It's not clear to me whether this ever matters, not to mention 3rd party log filtering tools may already rely on a particular format. Still it would be nice to have a single manifest constant and have every call to localtime/strftime consistently use the same format. Change-Id: I827cad7bf53e57b69c0173f67abe72884249c1a9 BUG: 832173 Signed-off-by: Kaleb S. KEITHLEY Reviewed-on: http://review.gluster.com/3568 Tested-by: Gluster Build System Reviewed-by: Anand Avati --- libglusterfsclient/src/libglusterfsclient.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) (limited to 'libglusterfsclient') diff --git a/libglusterfsclient/src/libglusterfsclient.c b/libglusterfsclient/src/libglusterfsclient.c index aaff4941..39b5bea5 100755 --- a/libglusterfsclient/src/libglusterfsclient.c +++ b/libglusterfsclient/src/libglusterfsclient.c @@ -110,7 +110,6 @@ zr_build_process_uuid () char tmp_str[1024] = {0,}; char hostname[256] = {0,}; struct timeval tv = {0,}; - struct tm now = {0, }; char now_str[32]; if (-1 == gettimeofday(&tv, NULL)) { @@ -125,9 +124,8 @@ zr_build_process_uuid () strerror (errno)); } - localtime_r (&tv.tv_sec, &now); - strftime (now_str, 32, "%Y/%m/%d-%H:%M:%S", &now); - snprintf (tmp_str, 1024, "%s-%d-%s:%ld", + gf_time_fmt (now_str, sizeof now_str, tv.tv_sec, gf_timefmt_Ymd_T); + snprintf (tmp_str, sizeof tmp_str, "%s-%d-%s:%ld", hostname, getpid(), now_str, tv.tv_usec); return strdup (tmp_str); -- cgit