Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:22066
Return-Path: <helly@php.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 70347 invoked by uid 1010); 1 Mar 2006 19:26:11 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 70332 invoked from network); 1 Mar 2006 19:26:11 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 1 Mar 2006 19:26:11 -0000
X-Host-Fingerprint: 81.169.182.136 ajaxatwork.net Linux 2.4/2.6
Received: from ([81.169.182.136:45032] helo=strato.aixcept.de)
	by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP
	id F7/62-37756-255F5044 for <internals@lists.php.net>; Wed, 01 Mar 2006 14:26:10 -0500
Received: from [192.168.1.3] (dslb-084-063-027-197.pools.arcor-ip.net [84.63.27.197])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(No client certificate requested)
	by strato.aixcept.de (Postfix) with ESMTP id C6C0435C1C1;
	Wed,  1 Mar 2006 20:26:07 +0100 (CET)
Date: Wed, 1 Mar 2006 20:26:23 +0100
Reply-To: Marcus Boerger <helly@php.net>
X-Priority: 3 (Normal)
Message-ID: <625666271.20060301202623@marcus-boerger.de>
To: Andi Gutmans <andi@zend.com>,
	Derick Rethans <derick@derickrethans.nl>,
	Dmitry Stogov <dmitry@php.net>, Ilia Alshanetsky <ilia@prohost.org>,
	Rasmus Lerdorf <rasmus@lerdorf.com>, Zeev Suraski <zeev@zend.com>
Cc: internals@lists.php.net
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: ZEND_HASH_APPLY_* confusion
From: helly@php.net (Marcus Boerger)

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