I actually agree.. The more macros we add, the more confusing it becomes. I had to look back and forth a few times between S_PASS() and Z_PASS() to figure it out. I guess Marcus was the one who wanted simpler API, so what does he think?

-Andrei

On Mar 7, 2006, at 4:06 AM, Dmitry Stogov wrote:

Hi,

The patch in attachment implements S_ARG(...) and related macroses.
However I don't like to commit it. Because code isn't more clear with these
macroses and it is harder to debug.
I prefer stay API as is.

Thanks. Dmitry.

-----Original Message-----
From: Dmitry Stogov [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 16, 2006 12:12 PM
To: php-i18n@lists.php.net
Subject: RE: [PHP-I18N] Ideas for a portable string api


Hi,

After reviewing Marcus ideas, some experiments and speaking
with Andrei. I propose the following solutions:

1) We will not use any kind of unicode literals in C code (no
L"foo" no "f\0o\0o\0\0"), Because L"" is not portable and
"f\0.." looks to ugly.

2) We will change "zval" structure to make
"zval.value.str.len" and "zval.value.ustr.len" of the same
type. This will allow optimize Z_UNISTR() and Z_UNILEN()
macros. They will

#define Z_UNISTR(z)  ((void*)(Z_STRVAL(z)))
#define Z_UNILEN(z)  ((void*)(Z_STRLEN(z)))

Instead of

#define Z_UNISTR(z)
Z_TYPE(z)==IS_UNICODE?(char*)Z_USTRVAL(z):Z_STRVAL(z)
#define Z_UNILEN(z)
Z_TYPE(z)==IS_UNICODE?(int)Z_USTRLEN(z):Z_STRLEN(z)

3)  I don't like to break source compatibility with
modification of "zval" layout as Marcus suggested. We will
pass string/unicode values near in the same way as do today.
As three values - zend_uchar type, void* str, int len. But we
will create a set of the following macros to do it with less overhead.

#define S_TYPE(x)               _type_##x
#define S_UNIVAL(x)             _val_##x
#define S_UNILEN(x)             _len_##x
#define S_STRVAL(x)             ((char*)S_UNIVAL(x))
#define S_USTRVAL(x)            ((UChar*)S_UNIVAL(x))
#define S_STRLEN(x)             S_UNILEN(x)             
#define S_USTRLEN(x)            S_UNILEN(x)

#define S_ARG(x)                zend_uchar S_TYPE(x), void
*S_UNIVAL(x), int
S_UNILEN(x)

#define S_PASS(x)               S_TYPE(x), S_UNIVAL(x), S_UNILEN(x)

#define Z_STR_PASS(x)           Z_TYPE(x), Z_UNIVAL(x), Z_UNILEN(x)
#define Z_STR_PASS_P(x) Z_TYPE_P(x), Z_UNIVAL_P(x),
Z_UNILEN_P(x)
#define Z_STR_PASS_PP(x)        Z_TYPE_PP(x), Z_UNIVAL_PP(x),
Z_UNILEN_PP(x)

Then most zend_u_... Functions must be rewriten with these macros

Foe example:

ZEND_API int zend_u_lookup_class(S_ARG(name), zend_class_entry ***ce
TSRMLS_DC)
{
        return zend_u_lookup_class_ex(S_PASS(name), 1, ce TSRMLS_CC); }

Instead of

ZEND_API int zend_u_lookup_class(zend_uchar type, void *name,
int name_length, zend_class_entry ***ce TSRMLS_DC) {
        return zend_u_lookup_class_ex(type, name, name_length,
1, ce TSRMLS_CC); }

Any objections, additions?

Thanks. Dmitry.

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



<s_arg.diff.gz>

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to