Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81213
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender)
Date: Tue, 27 Jan 2015 09:42:15 +0000 (GMT)
To: Joshua Rogers <honey@internot.info>
cc: internals@lists.php.net
In-Reply-To: <54BD5998.4050806@internot.info>
Message-ID: <alpine.DEB.2.11.1501270939570.4080@whisky.home.derickrethans.nl>
References: <1421694958-14772-1-git-send-email-git@internot.info> <54BD5998.4050806@internot.info>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] [PATCH] Fix potential int overflow in date
 extension.
From: derick@php.net (Derick Rethans)

On Tue, 20 Jan 2015, Joshua Rogers wrote:

> On 20/01/15 06:15, Joshua Rogers wrote:
> > --
> >  ext/date/lib/tm2unixtime.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> Somebody please take a look at /ext/date/lib/parse_tz.c too:
> 
> 438timelib_sll timelib_get_current_offset(timelib_time *t)
> [..]
> 446                        return (t->z + t->dst) * -60;
> Should that be cast timelib_sll too?
> 
> I think perhaps the function should be an int, seeing as it looks like
> the result should be negative. Somebody please check.

The result can be either positive or negative as t->z can be both. 
timelib_sll seems right though, as it stands for "long long signed".
I don't quite see how this can overflow though - as t->z and t->dst come 
just close to 100000 (and it's internal provided data).

cheers,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine