On 15.06.2009, at 15:40, Matt Wilmas wrote:
Hi David,
Hey Matt,
----- Original Message ----- From: "David Zülke" Sent: Monday, June 15, 2009Hi 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.
Aaah!
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...)
Yeah I guess that's the case here.
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(). :-/
It does help, absolutely. Thanks a lot! - David
smime.p7s
Description: S/MIME cryptographic signature
