Moriyoshi Koizumi wrote:
> moriyoshi Fri Sep 12 23:59:51 2008 UTC
>
> Modified files:
> /php-src/ext/mbstring mbstring.c
> Log:
> - The mb_list_* issue has been resolved in the following way:
> - Keep the same prototype as 5.2 for mb_list_encodings().
>
On 11.08.2008 19:40, Nuno Lopes wrote:
#include
#undef UChar
#elif HAVE_PCRE || HAVE_BUNDLED_PCRE
-#include
+#include "ext/pcre/php_pcre.h"
#endif
Right, I didn't notice that =)
Thanks.
--
Wbr,
Antony Dovgal
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://w
Hi, Derick.
> Just wondering... but why are you adding mb_String functions to HEAD?
> PHP in HEAD has full unicode support which makes the mbstring extension
> obsolete.
PHP_5_1 Branch is release process.
If PHP5.1.3 is released, it will be applied to PHP_5_1 Branch.
Can't think that all appli
On Thu, 30 Mar 2006, Seiji Masugata wrote:
> masugata Thu Mar 30 15:43:54 2006 UTC
>
> Modified files:
> /php-src/ext/mbstring mbstring.c mbstring.h
> Log:
> added mb_stripos( ), mb_strripos( ).
Just wondering... but why are you adding mb_String function
On 2003/12/19, at 0:12, Andi Gutmans wrote:
Shouldn't you be using some SEPARATE*() macro here? It seems as if
you're doing something like that.
I didn't try to use that macro because a zval_copy_ctor() call in it
would
be redundant in this case. It seems REPLACE_ZVAL_VALUE() is a more
suitable
Shouldn't you be using some SEPARATE*() macro here? It seems as if you're
doing something like that.
At 09:50 AM 12/18/2003 +, Moriyoshi Koizumi wrote:
moriyoshi Thu Dec 18 04:50:21 2003 EDT
Added files:
/php-src/ext/mbstring/tests bug26639.phpt
Modified files:
/php
On Tue, Nov 11, 2003 at 05:35:33PM -, Moriyoshi Koizumi wrote:
> moriyoshi Tue Nov 11 12:35:33 2003 EDT
>
> Modified files:
> /php-src/ext/mbstring mbstring.c
> Log:
> Compiler warning fix (patch by Joe Orton)
The fix is needed on the 4.3 branch too B
On October 26, 2003 02:20 am, Rui Hirokawa wrote:
> But, I shoudn't revert an another license related patch
> as shown below because the license compatibility has priority.
There is no argument about the license fix patch, it is a necessary evil. I
will make RC3 on Monday with this patch and if n
Moriyoshi,
Yes, there was a temporary agreement that allows us to release the current version in
the 4.3 branch until new implementation has stability.
But, I think replacing libmbfl with mbfilter.* in PHP 4.3.4 is preferable because,
1. license problem should be solved as quickly as possible
Rui, wasn't there any agreement with the author of libmbfl that still
allows us to keep the modified version in the 4.3 branch? Unless there's
something obvious, we'd be better off replacing them by the safer stuff
however.
Moriyoshi
Rui Hirokawa <[EMAIL PROTECTED]> wrote:
>
> Ilia,
>
> I ap
Ilia,
I appreciate your continious effort about QC process.
GPC bug in rfc1867.c is not critical one, and I agree with you
it is not preferable in the final RC process.
I will revert my GPC related patch in a couple of hours.
But, I shoudn't revert an another license related patch
as shown bel
Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> On October 25, 2003 07:14 pm, Rasmus Lerdorf wrote:
> > Ah, thought it was the other patch. However, I wouldn't call the above a
> > new feature. That one is a bug fix as it was an oversight to not also
> > convert form fields in multipart posts.
>
On October 25, 2003 07:14 pm, Rasmus Lerdorf wrote:
> Ah, thought it was the other patch. However, I wouldn't call the above a
> new feature. That one is a bug fix as it was an oversight to not also
> convert form fields in multipart posts.
Well, it is a mix of a feature & a bug fix. The bug if
I think it is a kind of bug fix because,
1. name field of multipart/form was not converted into internal encoding.
This behavior is different from the usual GPC conversion performed by
mbstr_treat_data() and it might makes confusion for the users.
2. auto-detection might be fail because auto-de
On Sat, 25 Oct 2003, Ilia Alshanetsky wrote:
> On October 25, 2003 06:22 pm, Rasmus Lerdorf wrote:
> > And continue breaking licenses knowingly?
>
> That patch does not fix licensing issues, it merely adds a feature, the
> license fix is not there...
>
> Patch log:
> name/value in multipart/fo
On October 25, 2003 06:22 pm, Rasmus Lerdorf wrote:
> And continue breaking licenses knowingly?
That patch does not fix licensing issues, it merely adds a feature, the
license fix is not there...
Patch log:
name/value in multipart/form-date will be converted into internal encoding
when mbstrin
And continue breaking licenses knowingly?
On Sat, 25 Oct 2003, Ilia Alshanetsky wrote:
> My appologies for the delayed response (I see that the patch was commited).
> After reviewing the patch I would very much prefer if you would revert it and
> wait till PHP 4.3.5 (ot whatever the next releas
My appologies for the delayed response (I see that the patch was commited).
After reviewing the patch I would very much prefer if you would revert it and
wait till PHP 4.3.5 (ot whatever the next release will be) with it.
Ilia
On October 24, 2003 11:08 pm, Rui Hirokawa wrote:
> Yes, I have plan
Yes, I have plan to commit to 4.3 branch.
Ilia, is it possible to commit ?
Rui
On Thu, 23 Oct 2003 10:43:16 +0900 (JST)
Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> Are you committing this to 4.3 as well?
>
> On Wed, 22 Oct 2003, Rui Hirokawa wrote:
>
> > hirokawaWed Oct 22 10:14:0
Are you committing this to 4.3 as well?
On Wed, 22 Oct 2003, Rui Hirokawa wrote:
> hirokawa Wed Oct 22 10:14:06 2003 EDT
>
> Modified files:
> /php-src/main rfc1867.c
> /php-src/ext/mbstring mbstring.c mbstring.h
> Log:
> name/value in multipart
20 matches
Mail list logo
