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.
