Re: signed long hash index for PHP7?
| From: | Andrea Faulds | Date: | Wed, 30 Jul 2014 02:44:20 +0000 |
| Subject: | Re: signed long hash index for PHP7? | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-76257@lists.php.net to get a copy of this message | ||
On 30 Jul 2014, at 03:37, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> Current Zend hash uses ulong for numeric array indexes.
> This causes bug #67693
>
> https://bugs.php.net/bug.php?id=67693
>
> Signed/unsigned mismatch is the root cause of this bug.
> Since PHP's int is signed by default, it might be better
> to change Zend hash index to signed long.
>
> I would like to hear comments who understand Zend internals. If there aren't
> issues, we may have signed long index for PHP7.
I noticed this myself (and am currently figuring out how to deal with it) while implementing bigints
in phpng (see my draft RFC for that). Converting from long to ulong and letting the sign just change
is madness, I’d fully support a move to signed longs. This would at least mean that integer
casting is the same as index casting, at least for floats (the fact we handle
[“9999999999999999999999999999999”] differently to [9999999999999999999999999999999] is a
different kettle of fish, but perhaps also worth discussing). Principle of least astonishment
applies, I think.
I think it was agreed with the 64-bit/phpng compromise that array indices should be 32-bit, but I
wonder also if having them be 64-bit might not be bad, to allow sparse arrays for example.
Note that my bigints RFC and patch don’t use bigint indices. While probably possible, I really,
really don’t want to try and implement that.
--
Andrea Faulds
http://ajf.me/