So I agree with your patch. :)
Probaly gettype() and settype() must be changed in the same way.
Thanks. Dmitry.
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 15, 2006 2:45 PM
> To: Dmitry Stogov
> Cc: 'Marcu
In case of "> is_string(): Z_TYPE_P() == IS_STRING || Z_TYPE_P() ==
IS_UNICODE",
is_string() will return TRUE for binary data in unicode mode.
It should be:
is_string(): Z_TYPE_P() == (UG(unicode)?IS_UNICODE:IS_STRING)
is_binary() and is_unicode() are OK.
Thanks. Dmitry.
> -Original Messa
ot a real problem. Buckets are always aligned by C compilers
or (e)malloc().
Thanks. Dmitry.
> -Original Message-
> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 13, 2006 12:02 PM
> To: Dmitry Stogov
> Cc: php-i18n@lists.php.net
> Subject: Re:
nteger index case".
Thanks. Dmitry.
> -Original Message-
> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> Sent: Sunday, March 12, 2006 1:59 PM
> To: Dmitry Stogov
> Cc: php-i18n@lists.php.net
> Subject: Re: [PHP-I18N] Hash api change
>
>
> Hello Dmitry,
>
Hi Marcus,
The idea make sense, but note that this modification will need two malloc()
for each bucket with string index.
First for bucket itself and the second for "arKey". (now they are done in
one call)
Also we will lose some performance in dereferencing pointer to arKey in each
ZendHash operat
OK. So common decision not ot apply this.
May be sombody will get some other ideas?
Thanks. Dmitry.
> -Original Message-
> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 07, 2006 10:39 PM
> To: Dmitry Stogov
> Cc: php-i18n@lists.php.net; Andrei
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 Stogo
ge-
> 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
M
> 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 (famo
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]
On Wednesday I'll available till 16:00 GMT.
Dmitry.
> -Original Message-
> From: Andi Gutmans [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 19, 2006 2:11 AM
> To: Tex Texin; 'Derick Rethans'; 'Marcus Boerger'
> Cc: 'Dmitry Stogov'
February 22 after 18:00 GMT+3 and February 23 are bad for me. (February 23
is a holiday in Russia).
Thanks. Dmitry.
> -Original Message-
> From: Tex Texin [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 17, 2006 12:00 PM
> To: 'Dmitry Stogov'; 'Andi Gutma
We already discussd these solutions with Andrei and Marcus.
I'll start implementation at Monday.
Thanks. Dmitry.
> -Original Message-
> From: Andi Gutmans [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 17, 2006 6:09 AM
> To: Dmitry Stogov; php-i18n@lists.php.net
&g
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 mak
14 matches
Mail list logo
