FW: [casting; overflow detection]

[Olson, Arthur David (NIH/NCI) [E]]

I'm forwarding this message from Christos Zoulas.

			--ado

-----Original Message-----
From: Christos Zoulas [mailto:christos at 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 at zoulas.com
        (connect to lecserver.nci.nih.gov[137.187.215.78]: Operation timed out)
	tz at lecserver.nci.nih.gov
						I
I sent the following two messages:

Best,

christos

>From christos Wed Jan 12 11:49:47 2011
From: christos at rebar.astron.com (Christos Zoulas)
Date: Wed, 12 Jan 2011 11:49:47 -0500
In-Reply-To: <201101121624.p0CGOrGD018457 at 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 at elsie.nci.nih.gov>, <tz at lecserver.nci.nih.gov>
Subject: Re: proposed time zone package changes (Hawaii, stack overflow, et al.)
Status: OR

On Jan 12, 11:24am, olsona at 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 at 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 at 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