> Nice API, I am a bit worried though about conversion routines. > Specifically, php_array_zval_to_double() uses different conversion > algorithm than PHP's standard zval to double conversion, which may > result in different results in edge cases. Also, these functions seem to > duplicate existing conversions - we already have code that converts > zvals to anything, couldn't we reuse it? BTW, it's not completely clear > what these conversion functions have to do with arrays - why they are > prefixed with php_array_*? If they aren't meant to be used directly, > maybe prefix them with __ or something? And if they are, maybe we need > better names for them... > Yeah, they're not meant to be called directly, just meant to be helpers.
> In php_array_zval_to_array() the comment says "If the value is an array, > then that zval is returned, otherwise NULL is returned." but the code > says (zarr && (Z_TYPE_P(zarr))) ? zarr : NULL; which means if zarr is > anything but NULL, it would be returned, regardless if it's array or not. > That would be a typo which didn't show up in my unit test. :) > There are a lot of functions that do: > char *k = estrndup(key, key_len); > Wouldn't it be more efficient to try to use alloca if it's available? > Probably. I'll change that. > "c" functions can be a bit dangerous, since they assume the argument is > a constant supplied directly in the macro, but there's no way to catch > it if somebody does something like name="foo"; php_array_fetchc(bar, foo); > Yeah, it was a micro-optimization I threw in for the hell of it. Already convinced it doesn't belong. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
