I already switched from "int32_t" to "int" and fix most places in ZE (except zend_unicode.c), but not in PHP extensions.
Also I see that some ZE functions use "unsigned int" and "size_t" for string length. Thanks. Dmitry. > -----Original Message----- > From: Andi Gutmans [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 23, 2006 5:03 AM > To: Marcus Boerger; Dmitry Stogov > Cc: 'Andrei Zmievski'; php-i18n@lists.php.net > Subject: Re: [PHP-I18N] Ideas for a portable string api > > > I think int is fine for this and we don't need to be super-accurate > on the unsigned for string length. This is how we work today and it's > a big change for no real gain. > > At 01:15 AM 2/21/2006, Marcus Boerger wrote: > >Hello Dmitry, > > > >Tuesday, February 21, 2006, 7:45:17 AM, you wrote: > > > > > I don't like int32_t because > > > > > 1) it is defined in ICU. > > > > int32_t is defined in <stdint.h> by ansi c 89. > > > > > 2) I will need to rewrite a lot of existing functions to use > > int32_t instead > > > of int. > > > >3) Both int and int32_t are wrong. The only correct choice would be > >size_t. > > > >best regards > >marcus > > > > > Thanks. Dmitry. > > > > >> -----Original Message----- > > >> From: Andi Gutmans [mailto:[EMAIL PROTECTED] > > >> Sent: Tuesday, February 21, 2006 9:26 AM > > >> To: Andrei Zmievski; Dmitry Stogov > > >> Cc: php-i18n@lists.php.net > > >> Subject: Re: [PHP-I18N] Ideas for a portable string api > > >> > > >> > > >> Is there a reason why? > > >> We usually just use int/uint almost anywhere... Then > again I don't > > >> really care because 32bit should be plenty (famous last > > >> words) for strings.... > > >> > > >> Andi > > >> > > >> At 10:16 PM 2/20/2006, Andrei Zmievski wrote: > > >> >I prefer to use fixed integer type, int32_t. > > >> > > > >> >-Andrei > > >> > > > >> > > > >> >On Feb 20, 2006, at 11:11 AM, Dmitry Stogov wrote: > > >> > > > >> >>Hi Andrei, > > >> >> > > >> >>We decide to use the same type for str.len (now int) and > > >> ustr.len (now > > >> >>int32_t, it comes from ICU). > > >> >> > > >> >>I prefer to make both of them - int. > > >> >>Any reclaims? I plan to do it at Thursday. > > >> >> > > >> >>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 > > >> >>> > > >> >>> > > >> > > > >> >-- > > >> >PHP Unicode & I18N Mailing List (http://www.php.net/) > > >> >To unsubscribe, visit: http://www.php.net/unsub.php > > >> > > >> > > >> > > > > > > > > > > > > > >-- > >Best regards, > > marcus > > -- > PHP Unicode & I18N Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > > -- PHP Unicode & I18N Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
