Re: ZEND_HASH_APPLY_* confusion

Yeah I think that making this consistent would have benefit. Would the semantics be relevant to all methods you looked at? Andi At 11:26 AM 3/1/2006, Marcus Boerger wrote:

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