Yeah, I think it makes more sense to stick to int and not change all
the places in extensions and the engine which count on that.I think
we can be pretty sure we'll have at least 32bit.
Andi
At 10:45 PM 2/20/2006, Dmitry Stogov wrote:
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
