Hi David,
----- Original Message -----
From: "David Zülke"
Sent: Monday, June 15, 2009
Hi folks,
while fixing http://bugs.php.net/bug.php?id=48557 I was wondering why
zend_hash_update doesn't automatically convert numeric strings to
integers.
Doing $foo = array('1' => 'bar'); actually results in an integer key with
value 1, not in a string. The problem in the bug above was that when
ext/soap decodes keys from a hashmap, it won't convert numeric string
keys to integers. As a result, such items in an array were never
accessible from PHP code (that is, unless you did some
array_keys()/array_values() stunts, of course).
Is this intentional? It seems that every internal feature that would like
to deal with hashes needs to implement this string->int casting behavior
of PHP itself. Why doesn't zend_hash_update() do it automatically?
I saw the patch there for Bug #48557, and the is_numeric_string() +
zend_hash/index/_update() isn't necessary -- that's what
zend_symtable_update() is for. :-) It's used elsewhere and takes care of
checking for numeric string keys.
hash_update() used to do that until the "symtable" variation was added
several years ago, and there were places in PHP that weren't updated and had
this issue. Obviously there's still one at least! (Or maybe that's newer
code that simply used the wrong function in the first place...)
I'm assuming hash_update() is intended to be an optimized version by only
working with strings, in places where it's already known -- in the engine,
walking through arrays where the type of key is already known, etc.
Kinda confusing, but hope that helps. Seems like they should've *added* a
new function that does what hash_update() now does, instead of basically
renaming the old version to symtable_update(). :-/
Cheers,
David
- Matt
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
