FAQ
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?

Cheers,

David

Search Discussions

  • Matt Wilmas at Jun 15, 2009 at 1:40 pm
    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
  • David Zülke at Jun 15, 2009 at 1:48 pm

    On 15.06.2009, at 15:40, Matt Wilmas wrote:

    Hi David,
    Hey Matt,

    ----- 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.
    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
  • David Zülke at Jun 15, 2009 at 2:16 pm
    Patch updated to reflect the change. It's against 5.3 btw. Now who
    will commit it so it makes it into the next RC? :)

    - David

    On 15.06.2009, at 15:47, David Zülke wrote:
    On 15.06.2009, at 15:40, Matt Wilmas wrote:

    Hi David,
    Hey Matt,

    ----- 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.
    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
  • Felipe Pena at Jun 15, 2009 at 5:36 pm
    Hi David,
    Em Seg, 2009-06-15 às 16:16 +0200, David Zülke escreveu:
    Patch updated to reflect the change. It's against 5.3 btw. Now who
    will commit it so it makes it into the next RC? :)
    I've committed it, thanks. (5.2+)


    --
    Regards,
    Felipe Pena

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedJun 15, '09 at 1:14p
activeJun 15, '09 at 5:36p
posts5
users3
websitephp.net

People

Translate

site design / logo © 2022 Grokbase