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: [email protected]
> >> 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: [email protected]
> >> >>>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