I'm forwarding this message from Christos Zoulas. --ado -----Original Message----- From: Christos Zoulas [mailto:christos@zoulas.com] Sent: Thursday, January 13, 2011 8:50 To: Olson, Arthur David (NIH/NCI) [E] Subject: Hi, Mail to the tz mailing list does not seem to go through from my server. E82CA564C4 2128 Thu Jan 13 04:00:52 christos@zoulas.com (connect to lecserver.nci.nih.gov[137.187.215.78]: Operation timed out) tz@lecserver.nci.nih.gov I I sent the following two messages: Best, christos
From christos Wed Jan 12 11:49:47 2011 From: christos@rebar.astron.com (Christos Zoulas) Date: Wed, 12 Jan 2011 11:49:47 -0500 In-Reply-To: <201101121624.p0CGOrGD018457@lecserver.nci.nih.gov> from Arthur David Olson (Jan 12, 11:24am) Organization: Astron Software X-Mailer: Mail User's Shell (7.2.6 beta(4.pl1)+dynamic 20000103) To: <tz@elsie.nci.nih.gov>, <tz@lecserver.nci.nih.gov> Subject: Re: proposed time zone package changes (Hawaii, stack overflow, et al.) Status: OR
On Jan 12, 11:24am, olsona@elsie.nci.nih.gov (Arthur David Olson) wrote: -- Subject: proposed time zone package changes (Hawaii, stack overflow, et al | If no problems are found, these changes will appear in tzcode2011a.tar.gz | and tzdata2011.tar.gz on 2011-11-23. Please don't cast the result of calloc(3). It will hide errors where the prototype is not in scope and then the function is assumed to return "int" which breaks on 64 bit systems. It's been more than 20 years (22 actually since c89) since ANSI C made allocation functions return "void *" :-) On a different subject, I've committed the reentrant versions of the timezone code to the NetBSD tree. Is there any chance that those changes will be merged anytime soon? Or do people need more time to review them? How do we go about accepting or rejecting them? Should there be a vote? Best, christos
From christos Wed Jan 12 23:00:52 2011 From: christos@rebar.astron.com (Christos Zoulas) Date: Wed, 12 Jan 2011 23:00:52 -0500 Organization: Astron Software X-Mailer: Mail User's Shell (7.2.6 beta(4.pl1)+dynamic 20000103) To: tz@lecserver.nci.nih.gov Subject: Gcc and integer overflow Status: OR
Hello, Integer overflow in ansi c has undefined behavior. Gcc 4.5.x takes advantage of this fact to optimize code. In particular you cannot depend anymore on: int oldx = x; x += delta; if ((oldx > x && delta > 0) || (oldx < x && delta < 0)) overflow; What happens in fact, is that gcc will warn, and drop the code that is "impossible" (drop the whole if statement). Unfortunately tzcode relies on the above behavior to detect overflow. I have changed the code the following way (but I have not tested it), so if you please can you check my work, or propose a better way to do it. I think we should come up with a viable solution for the next tzcode release. Many thanks, christos Index: localtime.c =================================================================== RCS file: /cvsroot/src/lib/libc/time/localtime.c,v retrieving revision 1.51 diff -u -u -r1.51 localtime.c --- localtime.c 6 Jan 2011 02:41:34 -0000 1.51 +++ localtime.c 10 Jan 2011 21:32:09 -0000 @@ -1703,9 +1703,16 @@ { int number0; + if (delta == 0) + return 0; + number0 = *number; *number += delta; - return (*number < number0) != (delta < 0); + + if (delta < 0) + return number0 < 0 && (-*number + INT_MIN) > delta; + else /* delta > 0 */ + return number0 > 0 && (INT_MAX - *number) < delta; } static int @@ -1713,9 +1720,16 @@ { long number0; + if (delta == 0) + return 0; + number0 = *number; *number += delta; - return (*number < number0) != (delta < 0); + + if (delta < 0) + return number0 < 0 && (-*number + LONG_MIN) > delta; + else /* delta > 0 */ + return number0 > 0 && (LONG_MAX - *number) < delta; } static int