I don't like int32_t because 1) it is defined in ICU.
2) I will need to rewrite a lot of existing functions to use int32_t instead of int. 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 > > > -- PHP Unicode & I18N Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
