Hello internals,
we have the consts:
#define ZEND_HASH_APPLY_KEEP 0
#define ZEND_HASH_APPLY_REMOVE 1<<0
#define ZEND_HASH_APPLY_STOP 1<<1
and the apply functions:
ZEND_API void zend_hash_apply(HashTable *ht, apply_func_t apply_func TSRMLS_DC);
ZEND_API void zend_hash_apply_with_argument(HashTable *ht, apply_func_arg_t
apply_func, void * TSRMLS_DC);
ZEND_API void zend_hash_apply_with_arguments(HashTable *ht, apply_func_args_t
apply_func, int, ...);
as well as:
ZEND_API void zend_hash_reverse_apply(HashTable *ht, apply_func_t apply_func
TSRMLS_DC);
we also have strange uscase:
static int clean_non_persistent_constant(zend_constant *c TSRMLS_DC)
{
if (c->flags & CONST_PERSISTENT) {
return EG(full_tables_cleanup) ? 0 : ZEND_HASH_APPLY_STOP;
} else {
return EG(full_tables_cleanup) ? 1 : ZEND_HASH_APPLY_REMOVE;
}
}
which actually would be the same as:
static int clean_non_persistent_constant(zend_constant *c TSRMLS_DC)
{
if (c->flags & CONST_PERSISTENT) {
return EG(full_tables_cleanup) ? ZEND_HASH_APPLY_KEEP :
ZEND_HASH_APPLY_REMOVE;
} else {
return ZEND_HASH_APPLY_REMOVE;
}
}
because normal apply functions only consider 0 and non 0.
Only the revese apply function takes the STOP constant into account.
Now obviously the case where a mixture of integres and consts is being
used didn't lead to a problem but we should make them correct anyway.
But i think we should also aim to make all apply functions aware of the
STOP const becuase in some cases it would mean a speedup.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
