Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65755
Return-Path: <Terry@ellisons.org.uk>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 46811 invoked from network); 10 Feb 2013 12:25:11 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 10 Feb 2013 12:25:11 -0000
Authentication-Results: pb1.pair.com smtp.mail=Terry@ellisons.org.uk; spf=permerror; sender-id=unknown
Authentication-Results: pb1.pair.com header.from=Terry@ellisons.org.uk; sender-id=unknown
Received-SPF: error (pb1.pair.com: domain ellisons.org.uk from 79.170.44.47 cause and error)
X-PHP-List-Original-Sender: Terry@ellisons.org.uk
X-Host-Fingerprint: 79.170.44.47 mail47.extendcp.co.uk  
Received: from [79.170.44.47] ([79.170.44.47:57635] helo=mail47.extendcp.co.uk)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id F5/54-20900-5A197115 for <internals@lists.php.net>; Sun, 10 Feb 2013 07:25:10 -0500
Received: from host86-184-170-184.range86-184.btcentralplus.com ([86.184.170.184] helo=[192.168.1.91])
	by mail47.extendcp.com with esmtpa (Exim 4.80.1)
	id 1U4Vxy-0004X6-Cz; Sun, 10 Feb 2013 12:25:06 +0000
Message-ID: <5117919F.1060806@ellisons.org.uk>
Date: Sun, 10 Feb 2013 12:25:03 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>
CC: PHP Internals <internals@lists.php.net>
References: <511666DE.8080809@fedoraproject.org> <CAEZPtU7wNj3GDD6GbLkZ-6KRAV_62Hj5QYzGiD7kLObtEbfEmg@mail.gmail.com> <5116D57F.6030802@ellisons.org.uk> <5117131B.2040606@sugarcrm.com> <51173F0C.2020403@ellisons.org.uk> <51174335.3090007@sugarcrm.com>
In-Reply-To: <51174335.3090007@sugarcrm.com>
Content-Type: multipart/alternative;
 boundary="------------020501060502020701000406"
X-Authenticated-As: Terry@ellisons.org.uk
Subject: Re: [PHP-DEV] double val to long val conversion issue
From: Terry@ellisons.org.uk (Terry Ellison)

--------------020501060502020701000406
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 10/02/13 06:50, Stas Malyshev wrote:
>> isn't the case with visualC, and PHP internal data structures compiled
>> with visualC and gcc are significantly different; for example hash keys
>> are 32 bits long on Windows and 64bits on *nix.  Why aren't they 32bits,
> Yes, they are different, because long size is different,
This my point: programmers from the *nix world tend to assume that longs 
are longer than ints.  In the MS world they are synonymous. This is one 
reason why code that has been developed in the *nix can be difficult to 
get working reliably in the MS world.
> and PHP uses
> long (more specific, ulong) to store hash values. This is because
> numeric values are long,
I don't follow this reasoning.  "Numeric value" in this context is a PHP 
(application space) concept.  Hashes are internal to the Zend EE and are 
never exposed to the PHP programmer, so this is a case of comparing 
apples and pears.  All that having a 64-bit hash does (when used % 
nTableSize which smaller than maxint) is to add 8 bytes to every Bucket 
entry stored by the EE for no practical benefit.

(It's 8 bytes because ulong h; uint nKeyLength; <long boundary> takes 16 
bytes but uint32 h; uint nKeyLength; <long boundary> takes 8 because of 
data alignment.)

> and it's easier to use the same type for both
> than bother with converting back and forth. As you noted, the difference
> for hashing is minimal since the value is anyway brought to hash size,
> and hashes of size more than 32-bit LONG_MAX aren't very practical.
> However, it matters in other parts of the code.


--------------020501060502020701000406--