Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:47535 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 90453 invoked from network); 23 Mar 2010 23:18:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Mar 2010 23:18:14 -0000 Authentication-Results: pb1.pair.com smtp.mail=michael@no-surprises.co.uk; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=michael@no-surprises.co.uk; sender-id=pass Received-SPF: pass (pb1.pair.com: domain no-surprises.co.uk designates 80.68.93.37 as permitted sender) X-PHP-List-Original-Sender: michael@no-surprises.co.uk X-Host-Fingerprint: 80.68.93.37 river.mgdm.net Received: from [80.68.93.37] ([80.68.93.37:38057] helo=river.mgdm.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 8A/72-12746-53C49AB4 for ; Tue, 23 Mar 2010 18:18:14 -0500 Received: from [192.168.1.118] (213-78-200-191.ppp.onetel.net.uk [213.78.200.191]) (Authenticated sender: michael) by river.mgdm.net (Postfix) with ESMTPSA id E2A4EDF3EC; Tue, 23 Mar 2010 23:18:09 +0000 (GMT) Message-ID: <4BA94C31.2020308@no-surprises.co.uk> Date: Tue, 23 Mar 2010 23:18:09 +0000 User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: sean finney CC: internals@lists.php.net References: <4BA93A30.4040003@no-surprises.co.uk> <20100323224105.GA9531@rangda.stickybit.se> In-Reply-To: <20100323224105.GA9531@rangda.stickybit.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [PATCH] FNV-1 support for ext/hash From: michael@no-surprises.co.uk (Michael Maclean) sean finney wrote: > On Tue, Mar 23, 2010 at 10:01:20PM +0000, Michael Maclean wrote: >> The patch: >> http://mgdm.net/~michael/patches/php-fnv.txt > > just to throw something out there, shouldn't the various inputLen > parameters be of type size_t instead of unsigned int? The function signature in php_hash.g says unsigned int, so that's what I used (though I note some of the other algorithms appear not to). We don't support files > 2^32 on 64-bit, so as I understand it, it's not going to cause issues right now, but if a large file support patch lands it's something that I might revisit. -- Cheers, Michael