Re: PHP3 and 64-bit land

From: Date: Sat, 27 Feb 1999 17:23:51 +0000
Subject: Re: PHP3 and 64-bit land
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-4343@lists.php.net to get a copy of this message
On Sat, 27 Feb 1999 sas@schell.de wrote: > On Sat, Feb 27, 1999 at 06:50:13PM +0200, Zeev Suraski wrote: > > > > > > On Sat, 27 Feb 1999 sas@schell.de wrote: > > > > > Well, I don't intend to change that specific part. It appears to me that > > > index_ptr is just recycled. > > > > As a general approach, PHP usually uses void pointers to store any > > enumerated type (long, pointer, int, etc). There's one exception I can > > think of, which is the hash, that uses unsigned integers to store the > > numeric offsets. > > Resources use hash tables to store themselves, and they usually use the > > numeric indices. I think it's extremely safe to use 32-bit integers as > > unique identifiers for 64-bit pointers, by simply casting them. You'd > > have to be extremely unlucky to bump into a problem because of this data > > loss. Your chances of winning the lottery are much much bigger. > > I disagree here. The chance of having the same ptr in 32 bit is about 1 in > 2^32 = 4,294,967,296. If you come to Germany, your chance to win the lottery > ("6 aus 49") is about 1 to 49!/43! = 10,068,347,520. Hmm, ok, we'll stay with the Israeli lottery here. > It's extremly safe, but you risk random, non repeatable crashes produced by > playing that way. Considering this as a risk is simply wrong. It's more or less like saying CRC-32 isn't reliable (there's a difference, but not inherent). Either way, you don't risk crashes, at worse, you simply don't find the resource you're looking for. Zeev -- ----------------------------------------------------- Zeev Suraski <zeev@zend.com> For a PGP public key, finger bourbon@netvision.net.il -- PHP Development Mailing List http://www.php.net/ To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net For help: php-dev-help@lists.php.net

« previous php.dev (#4343) next »