Re: [PHP-DEV] fputcsv()

2004-04-11 Thread Moriyoshi Koizumi
On 2004/04/12, at 1:33, David Sklar wrote: Attached is a patch that implements fputcsv() as a complement to fgetcsv(). There are two things that still need improvement: - It adds "\n" as a newline onto the end of each line. I think it would be better to add a platform-specific line ending. -

Re: [PHP-DEV] Input Filters - Bugs? - PHP4 Port

2004-06-26 Thread Moriyoshi Koizumi
On 2004/06/26, at 3:36, Stefan Esser wrote: I am asking, because this is not properly documented and atleast the mbstring extension violates this. mbstring extention doesn't actually use "input filter" stuff, but it had initially been merged to SAPI as a ugly "hack" long before the input filter wa

[PHP-DEV] Fix for bug #28325

2004-06-29 Thread Moriyoshi Koizumi
I made a patch for bug #28325. I'd like to see this one applied by the time PHP5 gets out of the door. http://www.voltex.jp/patches/bug28325-preliminary.patch.diff Regards, Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Fix for bug #28325

2004-07-01 Thread Moriyoshi Koizumi
On 2004/07/01, at 14:25, Andi Gutmans wrote: Hi Moriyoshi, The object handle is not a unique identifier. Different object types (e.g. PHP objects, SimpleXML objects) can have the same object handle. The real unique identifier is object handle + object handlers array or more useful in your case,

Re: [PHP-DEV] Re: Fix for bug #28325

2004-07-01 Thread Moriyoshi Koizumi
class can rarely be recognised wrongly with this code as long as blk (or mmap) call is sane and it properly maps the physical memory to the VM space. Moriyoshi On 2004/07/01, at 16:03, Moriyoshi Koizumi wrote: On 2004/07/01, at 14:25, Andi Gutmans wrote: Hi Moriyoshi, The object handle is not a

Re: [PHP-DEV] issue in copying the hash table(Reposted third time)

2004-07-07 Thread Moriyoshi Koizumi
On 2004/07/07, at 14:18, Kamesh Jayachandran wrote: In this case while making a copy og global_class_table to thread specific class_table in a deep fashion. zend_hash_copy has to do the double dereferencing which it can't being a generic fuinction. Sorry, but I don't quite understand what you meant

Re: [PHP-DEV] issue in copying the hash table(Reposted third time)

2004-07-07 Thread Moriyoshi Koizumi
On 2004/07/08, at 1:04, Kamesh Jayachandran wrote: My question is very simple. Please answer the following question. 1)Zend has global_class_table of type HashTable with a key as the class name ('char*') and value of type 'zend_class_entry**'. True or False? Keys are just strings and associated val

Re: [PHP-DEV] issue in copying the hash table(Reposted third time)

2004-07-08 Thread Moriyoshi Koizumi
On 2004/07/08, at 14:41, Kamesh Jayachandran wrote: The last parameter sizeof(zend_class_entry) of value say 292 to zend_hash_copy indicate it to dereference the value of one of the hashtable entry. This value is of type zend_class_entry** which when dereferenced once gives rise to zend_class_entry

Re: [PHP-DEV] issue in copying the hash table(Reposted third time)

2004-07-10 Thread Moriyoshi Koizumi
On 2004/07/08, at 19:16, Kamesh Jayachandran wrote: Hi Moriyoshi, Sorry to copy the INIT_DATA macro in the mail. #define INIT_DATA(ht, p, pData, nDataSize) if (nDataSize == sizeof(void*)) { memcpy(&(p)->pDataPtr, pData, sizeof(void *)); (p)->pData = &(p)->pDataPtr; } else { (p)

Re: [PHP-DEV] php_compat.h in ext/mbstring/oniguruma

2004-07-18 Thread Moriyoshi Koizumi
done (VPATH fix applied as well). Joe Orton wrote: >I think this file needs to be renamed; the 5.0.0 build fails using >mbregex and pcre with bundled pcre, for instance, since the bundled pcre >picks up the wrong php_compat.h and the #define pcre_* aren't picked up. > >Renaming it to php_onigurum

Re: [PHP-DEV] No safe_pemalloc()?

2004-07-20 Thread Moriyoshi Koizumi
On 2004/07/20, at 14:10, Sara Golemon wrote: Is there any reason there's no safe_pemalloc()? I once had exactly the same thought. Probably because there'd be no need for persistence, and stream folks now obviously need it :) Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsub

Re: [PHP-DEV] No safe_pemalloc()?

2004-07-20 Thread Moriyoshi Koizumi
ersistent)?free(ptr):efree(ptr)) #define pecalloc(nmemb, size, persistent) ((persistent)?calloc((nmemb), (size)):ecalloc((nmemb), (size))) #define perealloc(ptr, size, persistent) ((persistent)?realloc((ptr), (size)):erealloc((ptr), (size))) On 2004/07/21, at 0:57, Zeev Suraski wrote: At 16:26 2

Re: [PHP-DEV] No safe_pemalloc()?

2004-07-20 Thread Moriyoshi Koizumi
On 2004/07/21, at 6:11, Andi Gutmans wrote: Looks good but why not rename the function to _safe_pemalloc()? (And of course rename to safe_pemalloc() as you do later on. Because it's there just for persistent allocation, while pemalloc() can be used both ways. Moriyoshi -- PHP Internals - PHP Ru

[PHP-DEV] 4.3.8 patches not yet applied to PHP_4_3 ?

2004-07-21 Thread Moriyoshi Koizumi
Hi, It seems 4.3.8 patches are not merged to PHP_4_3 yet. Is there any reason to refrain from doing so? Regards, Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 4.3.8 patches not yet applied to PHP_4_3 ?

2004-07-21 Thread Moriyoshi Koizumi
On 2004/07/22, at 0:50, Stefan Esser wrote: What patches are you speaking about? Those which are likely intended for CAN-2004-0594. For instance, hallmark:~/Documents/Sources/php-src-4 moriyoshi$ cvs diff -r 1.512.2.53.2.1 main/main.c Index: main/main.c ===

Re: [PHP-DEV] Request: Support for a memory_limit exploit paper needed

2004-08-01 Thread Moriyoshi Koizumi
Hi, The package includes a description how the test works. It basicly consists of compiling PHP on your normal platform: f.e. OpenBSD Apache2 CGI. You should just add --enable-memory-limit to your standard configure line and turn register_globals on. The rest is all explained in the package. Is

Re: [PHP-DEV] Request: Support for a memory_limit exploit paper needed

2004-08-02 Thread Moriyoshi Koizumi
What a stupid question I asked here... Nevermind. Moriyoshi On 2004/08/02, at 8:11, Moriyoshi Koizumi wrote: Hi, The package includes a description how the test works. It basicly consists of compiling PHP on your normal platform: f.e. OpenBSD Apache2 CGI. You should just add --enable-memory

Re: [PHP-DEV] Status of Multibyte support in PHP

2004-08-27 Thread Moriyoshi Koizumi
Hi, On 2004/08/28, at 5:15, Al Baker wrote: I'm trying to find status on the multibyte support in PHP. The manual shows the functions in mbstring to be experimental and it's hard to find evidence of how stable it really is. Which manual says that mbstring is still experimental? :) it was marked "

Re: [PHP-DEV] Status of Multibyte support in PHP

2004-08-28 Thread Moriyoshi Koizumi
Hi, On 2004/08/28, at 8:38, Al Baker wrote: Thanks for the confirmation. The experimental warning appears on any of the individual help files for mbstring (e.g. mb_ereg). Hmm, warnings seem to persist in manual pages of the multibyte regular expression functions. I'll remove them later :) Do you

Re: [PHP-DEV] Status of Multibyte support in PHP

2004-08-28 Thread Moriyoshi Koizumi
On 2004/08/28, at 8:17, Sean Coates wrote: Are these functions in fact non-experimental? If so, I will remove the warning from the mb_* functions in the manual. Yep, definitely. Thanks in advance :) Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www

Re: [PHP-DEV] [PATCH PHP_4_3] Core dumps in cyrus

2004-10-14 Thread Moriyoshi Koizumi
Hi, Thank you for the patch. Cyrus extension is now in PECL (http://pecl.php.net/) and I'm the primary maintainer of it. I think the problems you pointed out were already addressed and fixed in CVS. Please check out the source at http://cvs.php.net/cvs.php/pecl/cyrus/ and send me a patch if you sti

Re: [PHP-DEV] iconv's input_encoding useless?

2004-10-05 Thread Moriyoshi Koizumi
Seems like a documentation problem. Since its introduction the iconv extension has never had such a function that converts the HTTP queries into those of another encoding, so that setting is useless at all. But there is the opposite function that converts the output into another encoding. Could you

Re: [PHP-DEV] Re: streams file uri under windows

2004-10-27 Thread Moriyoshi Koizumi
On 2004/10/28, at 0:55, Sara Golemon wrote: That said libsmb is GPL so any implementation would have to start from scratch or live outside of php.net AFAIK FreeBSD's libsmb is released under a BSD-style license. http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/smbfs/lib/smb/ Moriyoshi -- PHP Inter

Re: [PHP-DEV] Re: streams file uri under windows

2004-10-27 Thread Moriyoshi Koizumi
On 2004/10/27, at 23:28, Rob Richards wrote: It adds support for file://localhost/ on all platforms as well as adding the file:/// support back under windows. Other than that it doesnt change how the remote host stuff is handled. Couldn't file://127.0.0.1/... or file://[::1]/... be valid URL's for

Re: [PHP-DEV] Re: streams file uri under windows

2004-10-27 Thread Moriyoshi Koizumi
On 2004/10/28, at 2:24, [EMAIL PROTECTED] wrote: Moriyoshi Koizumi <[EMAIL PROTECTED]> writes: AFAIK FreeBSD's libsmb is released under a BSD-style license. http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/smbfs/lib/smb/ That's not libsmb; rather, it's the kernel modul

Re: [PHP-DEV] Re: streams file uri under windows

2004-10-27 Thread Moriyoshi Koizumi
On 2004/10/28, at 3:28, Rob Richards wrote: From: Moriyoshi Koizumi Couldn't file://127.0.0.1/... or file://[::1]/... be valid URL's for the local resources? To play it safe I would say no right now. The file uri stuff is being worked on again: http://www.ietf.org/internet-drafts/dra

Re: [PHP-DEV] localeconv not working

2004-11-03 Thread Moriyoshi Koizumi
On 2004/10/30, at 21:43, Klaus Reimer wrote: I think this explains the misbehaviour. If I do a "setlocale(LC_ALL, 'de_DE')" then the PHP function resets LC_NUMERIC to "C". So what chance have I to get the LC_NUMERIC configuration of a specific locale now? Well, I think there was a good reason to

Re: [PHP-DEV] localeconv not working

2004-11-03 Thread Moriyoshi Koizumi
On 2004/11/03, at 17:11, Derick Rethans wrote: It's assigned to me for now... I'll have a look at it this week. Does somebody remember why we need to mangle the locale anyway by resetting LC_NUMERIC to "C"? Good to hear the problem is then going to be addressed. According to the annotation, the cha

Re: [PHP-DEV] localeconv not working

2004-11-03 Thread Moriyoshi Koizumi
On 2004/11/03, at 18:57, Derick Rethans wrote: I think a much better solution would be to use our own "strtod" function that isn't affected by locales then. I guess we could borrow a BSD implementatino of it and modify this to our needs. My +1 if some vote will take place. See also: http://marc.th

Re: [PHP-DEV] serialize bug with array that references to itself?

2004-11-03 Thread Moriyoshi Koizumi
On 2004/11/03, at 22:31, Andrey Hristov wrote: $c=array($a,$b); var_dump($c,$d=serialize($c)); var_dump($e=unserialize($d)); $d[0]->a->prop=1; var_dump($d); ?> Did you mean "$e[0]->a->prop" by "$d[0]->a->prop"? That looks like another issue: a->prop = 1; ?> Moriyoshi -- PHP Internals - PHP Runtime

Re: [PHP-DEV] serialize bug with array that references to itself?

2004-11-03 Thread Moriyoshi Koizumi
> > Did you mean "$e[0]->a->prop" by "$d[0]->a->prop"? > > Well, when I was writing the test I made a mistake which > I saw later but my mistake lead to a PHP core dump. Looks more like I should've read the mail more carefully :) Moriyoshi -- PHP Internals - PHP Runtime Development Mailing Lis

[PHP-DEV] Module activation order in php_request_startup()

2004-12-28 Thread Moriyoshi Koizumi
Hi, Currently activation functions are called in the following order on request startup: 1. zend_activate() 2. sapi_activate() 3. php_hash_environment() 4. zend_activate_modules() Is there any good technical reason behind this order? I don't think it does make much sense because php_hash_environmen

[PHP-DEV] extract(EXTR_REFS) and pass-by-reference

2005-01-01 Thread Moriyoshi Koizumi
Hi there, I'm now looking into the three extract() bugs related to each other, namely bug #25708, bug #29493 and bug #31213. It turned out after all that these problems are caused by a inevitable zval separation on sending arguments to the function and there seems to be no feasible workaround for n

Re: [PHP-DEV] extract(EXTR_REFS) and pass-by-reference

2005-01-04 Thread Moriyoshi Koizumi
On 2005/01/02, at 21:23, Marcus Boerger wrote: while i tried to improve performance of the array functions i developed a new pass type - pass as const which doesn't touch the passed variable at all and is compatible with temp vars, too. Maybe your problem here is a reason to really implement that

Re: [PHP-DEV] extract(EXTR_REFS) and pass-by-reference

2005-01-05 Thread Moriyoshi Koizumi
On 2005/01/05, at 1:31, Andi Gutmans wrote: At 06:26 PM 1/4/2005 +0900, Moriyoshi Koizumi wrote: On 2005/01/02, at 21:23, Marcus Boerger wrote: while i tried to improve performance of the array functions i developed a new pass type - pass as const which doesn't touch the passed variable a

Re: [PHP-DEV] Segmentation fault in html_entity_decode

2005-01-11 Thread Moriyoshi Koizumi
Now fixed in CVS. Thanks for the good report. Moriyoshi On 2005/01/10, at 22:30, Kamesh Jayachandran wrote: Hi All, The following script causes a segmentation fault in NetWare but not on Windows or Linux versions of php-5.0.3 I can not attribute to NetWare instead I could see the defect in our ext

[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_compile.c

2005-01-12 Thread Moriyoshi Koizumi
On 2005/01/12, at 9:24, Andi Gutmans wrote: Are you sure this is the right fix? After all, last_op->result.u.var should already have a temporary variable assigned for when the opcode was generated. When exactly did you find this is not the case? As far as I checked, at least a temporary variable

[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_compile.c

2005-01-12 Thread Moriyoshi Koizumi
On 2005/01/12, at 17:12, Moriyoshi Koizumi wrote: However, it looks like the rule doesn't apply to the current HEAD. Copy'n'paste mistake.. This part should have been like Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Segmentation fault in html_entity_decode

2005-01-12 Thread Moriyoshi Koizumi
LL, NULL, NULL, NULL, "sdot", NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, /* 8912 (0x22d0) */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, /* 8928 (0x22e0) */ NULL, NULL, NULL

[PHP-DEV] Re: #31098 [Csd]: isset false positive

2005-01-12 Thread Moriyoshi Koizumi
Hi Dmitry, On 2005/01/12, at 18:28, [EMAIL PROTECTED] wrote: patch for HEAD is incorrect. You must not edit zend_vm_execute.h directly. You must edit zend_vm_def.h and then generate zend_vm_execute.h with zend_vm_gen.php. See README.ZEND_VM for more details. Excuse me for my ignorance & thank you f

[PHP-DEV] Re: #31098 [Csd]: isset false positive

2005-01-13 Thread Moriyoshi Koizumi
On 2005/01/13, at 15:21, <[EMAIL PROTECTED]> wrote: I don't quite agree with you. Indeed it's semantically wrong, yet I think we leave it to behave as in ZE1, in terms of backwards compatibility. I don't think we must make compatibility for bugs. Users don't consider a certain behaviour that lasts

[PHP-DEV] Reversion of patch for bug #31398

2005-01-23 Thread Moriyoshi Koizumi
Ilia, While your opinion that we shouldn't count on the "filename" attribute in multiparted queries is quite to the point, your patch totally disregards the old behaviour. We must neither use php_basename() for pathes of a spec different from that defined by the platform which is determined in comp

Re: [PHP-DEV] iconv doesn't built on OSX

2005-02-08 Thread Moriyoshi Koizumi
I've experienced the same. The following improper change was left forgotten when Jani applied his fix that is eventually correct. http://cvs.php.net/diff.php/php-src/acinclude.m4?r1=1.275&r2=1.276&ty=u Moriyoshi On 2005/02/09, at 3:55, Christian Stocker wrote: Hi After a long look into the configur

Re: [PHP-DEV] iconv doesn't built on OSX

2005-02-10 Thread Moriyoshi Koizumi
On 2005/02/10, at 22:13, Jani Taskinen wrote: Please blame the correct people, not always by default ME. :) I never touched this macro, it was andrei: I didn't blame you, but I just wanted to say you did it right :) Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubs

Re: [PHP-DEV] [PATCH] ext/xml/compat.c fix for #32001

2005-02-17 Thread Moriyoshi Koizumi
On 2005/02/17, at 22:28, Joe Orton wrote: So it is a bit of a tricky trade-off... How about #ifdef'ifying it? It's lame though... Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] XML Bug #32001

2005-03-10 Thread Moriyoshi Koizumi
On 2005/03/11, at 10:24, Marcus Boerger wrote: Hello moriyoshi or any other XMLer, please verify the --EXPECT-- data in test ext/xml/tests/bug32001.phpt i am quite sure there are several mistakes in it. Excuse me if I'm just missing something, what kind of mistake do you want to address? Moriyosh

Re: [PHP-DEV] XML Bug #32001

2005-03-11 Thread Moriyoshi Koizumi
esn't make any sense if it doesn't work perfectly and we better deprecate it until some unicode-aware case folding function is available. Moriyoshi Rob Moriyoshi Koizumi wrote: On 2005/03/11, at 10:24, Marcus Boerger wrote: Hello moriyoshi or any other XMLer, please verify the --EXPECT-- d

Re: [PHP-DEV] HALT Patch

2005-03-11 Thread Moriyoshi Koizumi
Hi, I modified your patch so it can capture the position where the supposed data begins into the constant __HALT_PHP_PARSER__. There may be a problem with my patch if more than one require()'d / include()'d script contain __HALT_PHP_PARSER__, but it'd be quite handy if such an issue is resolved.

Re: [PHP-DEV] reference issue

2005-03-17 Thread Moriyoshi Koizumi
That's expected behaviour. Have a look at http://bugs.php.net/20993 . The problem can also be prevented by the following hack: // modifying and assining branch causes unexpexted results to $this->tree $metatree[$object_id] = (array)unserialize(serialize($branch)); Regards, Moriyoshi On 2005/03/17

Re: [PHP-DEV] reference issue

2005-03-17 Thread Moriyoshi Koizumi
On 2005/03/17, at 21:52, Lukas Smith wrote: Derick Rethans wrote: On Thu, 17 Mar 2005, Moriyoshi Koizumi wrote: That's expected behaviour. Have a look at http://bugs.php.net/20993 . Sorry, but this is not expected - it's a bug. I would also like to disagree. I think this is a huge inc

Re: [PHP-DEV] implode() speedup in PHP4

2005-03-18 Thread Moriyoshi Koizumi
On 2005/03/19, at 3:41, Alexander Valyalkin wrote: I've posted patch last summer http://www.zend.com/zend/week/pat/pat5.txt which imporves performance of implode() function in PHP4, but nobody doesn't commit it yet. Can anybody explain the reason? Because convert_to_string_ex() modifies the conte

Re: [PHP-DEV] implode() speedup in PHP4

2005-03-18 Thread Moriyoshi Koizumi
On 2005/03/19, at 6:14, Derick Rethans wrote: On Sat, 19 Mar 2005, Moriyoshi Koizumi wrote: We already have an optimisation in the 5.x branches. I think it is appliable to the 4.3 branch. 4.3 is only for bugfixes! It didn't mean that the fix should be in the 4.3. What was it that excited y

[PHP-DEV] RFC: Removing PHP tags

2012-03-31 Thread Moriyoshi Koizumi
Hi, I wrote a RFC that proposes removal of PHP tags. There is actually strong public demand for it, and I also think it is necessary to leverage PHP to a genuine, modern scripting language. http://wiki.php.net/rfc/nophptags Regards, Moriyoshi -- PHP Internals - PHP Runtime Development Mailing

Re: [PHP-DEV] RFC: Removing PHP tags

2012-03-31 Thread Moriyoshi Koizumi
Ok, I'll try to fix that part. Thanks for the correction. Moriyoshi On Sun, Apr 1, 2012 at 11:29 AM, Rasmus Lerdorf wrote: > On Mar 31, 2012, at 6:59 PM, Moriyoshi Koizumi wrote: > >> Hi, >> >> I wrote a RFC that proposes removal of PHP tags.  There is actually &

[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/standard array.c

2009-02-15 Thread Moriyoshi Koizumi
Moriyoshi > > On 14-Feb-09, at 9:12 PM, Moriyoshi Koizumi wrote: > >> So, what are RM's thoughts on this? My points are: >> >> 1. Making SORT_REGULAR default *actually* broke existing code. >> 2. Adding the second argument addressed the problem enough that th

[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/standard array.c

2009-02-17 Thread Moriyoshi Koizumi
Anyone's thoughts on this? I'm thinking of re-reverting in 48 hours without further objections. Moriyoshi On Sun, Feb 15, 2009 at 11:48 PM, Moriyoshi Koizumi wrote: > Ilia Alshanetsky wrote: >> I've discussed this issue with Andrei at least a month ago (if not >&

[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/standard array.c

2009-02-17 Thread Moriyoshi Koizumi
On Wed, Feb 18, 2009 at 3:11 AM, Andrei Zmievski wrote: > SORT_STRING can only reliably deal with strings - its behavior on non-string > type is basically broken. Unless we agree that PHP is Tcl (strings are the > only type), then SORT_REGULAR makes much more sense to me, and evidently > others.

[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/standard array.c

2009-02-17 Thread Moriyoshi Koizumi
In addition, we should look at similar comparison-involved array functions such as array_intersect, array_diff and so on, otherwise it's gonna be a mess. Moriyoshi On Wed, Feb 18, 2009 at 11:43 AM, Moriyoshi Koizumi wrote: > On Wed, Feb 18, 2009 at 3:11 AM, Andrei Zmievski

Re: [PHP-DEV] Re: Bug #46701

2009-02-18 Thread Moriyoshi Koizumi
merged, then bug #46701 should be reverted from the 5.2 branch. Moriyoshi On Wed, Feb 18, 2009 at 8:28 PM, zoe wrote: > Moriyoshi Koizumi wrote: >>>>> I guess the patch relies on the 5.3's DVAL_TO_LVAL behavior that was >>>>> changed by the fix for bug #42868, rig

[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/standard array.c

2009-02-18 Thread Moriyoshi Koizumi
On Thu, Feb 19, 2009 at 4:51 AM, Andrei Zmievski wrote: > Moriyoshi Koizumi wrote: >> >> As I said earlier, the function is never supposed to be used with >> objects. Therefore, we cannot declare it to be broken, and any change >> to the behavior anyway leads to a hu

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/standard array.c

2009-02-18 Thread Moriyoshi Koizumi
On Thu, Feb 19, 2009 at 3:14 PM, Ian Eure wrote: > On Feb 18, 2009, at 6:52 PM, Moriyoshi Koizumi wrote: > >> On Thu, Feb 19, 2009 at 4:51 AM, Andrei Zmievski >> wrote: >>> >>> Moriyoshi Koizumi wrote: >>>> >>>> As I said earlier,

Re: [PHP-DEV] FD_SETSIZE limitation

2009-02-19 Thread Moriyoshi Koizumi
That's because struct fd_set, which is manipulated by FD_SET, is a struct that contains a fixed-size array. Moriyoshi Andrei Zmievski wrote: > Can someone explain why ext/sockets and also stream socket functions > care about FD_SETSIZE? > > # define PHP_SAFE_FD_SET(fd, set) do { if (fd < FD_SE

Re: [PHP-DEV] FD_SETSIZE limitation

2009-02-19 Thread Moriyoshi Koizumi
Robin Burchell wrote: > On Thu, Feb 19, 2009 at 10:24 PM, Andrei Zmievski > wrote: >> Can someone explain why ext/sockets and also stream socket functions care >> about FD_SETSIZE? > > They care, because they use the select(2) syscall, which cares about > FD_SETSIZE. > select(2) itself can ha

[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/standard array.c

2009-02-25 Thread Moriyoshi Koizumi
Last call: any more objections? Moriyoshi On Thu, Feb 19, 2009 at 11:52 AM, Moriyoshi Koizumi wrote: > On Thu, Feb 19, 2009 at 4:51 AM, Andrei Zmievski > wrote: >> Moriyoshi Koizumi wrote: >>> >>> As I said earlier, the function is never supposed to be used w

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h

2009-02-26 Thread Moriyoshi Koizumi
So, in what point do you guys think of this change as valid? Moriyoshi On Thu, Feb 26, 2009 at 11:36 PM, Antony Dovgal wrote: > On 26.02.2009 17:19, Ilia Alshanetsky wrote: >> Let's reach a conclusion by end of day (EST time) so release can either be >> made or >> delayed. > > +0 > > Just go ah

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h

2009-02-26 Thread Moriyoshi Koizumi
Robin Burchell wrote: > On Thu, Feb 26, 2009 at 5:21 PM, Moriyoshi Koizumi wrote: >> So, in what point do you guys think of this change as valid? >> >> Moriyoshi > > Is there any known examples of code broken by this, or is it a more > academic than practical p

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h

2009-02-26 Thread Moriyoshi Koizumi
On Fri, Feb 27, 2009 at 3:58 AM, Moriyoshi Koizumi wrote: > 1. array_unique() has never been supposed to handle values other than > strings. That's how bug #10658 is handled. That's not what I really wanted to mean. I should have said "not supposed to handle valu

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h

2009-02-26 Thread Moriyoshi Koizumi
as > possible as it introduces a number of crucial fixes and if your comments are > validated via user feedback we can adjust the values with 5.2.10 that can be > repackaged fairly rapidly. IMHO the current functionality is desired and is > acceptable. > > Ilia Alshanetsky > > &

[PHP-DEV] max_execution_time and async signal handling in apache2handler

2009-03-15 Thread Moriyoshi Koizumi
Hi, I got a bug report on the Japanese PHP user's list that states free() aborts within the timer signal handler due to reentrance to the function when max_execution_time takes effect and the signal occurs within the same libc function. The reporter also states he uses apache2handler, which doesn'

Re: [PHP-DEV] max_execution_time and async signal handling in apache2handler

2009-03-15 Thread Moriyoshi Koizumi
i Moriyoshi, > > Moriyoshi Koizumi wrote: >> >> Hi, >> >> I got a bug report on the Japanese PHP user's list that states free() >> aborts within the timer signal handler due to reentrance to the >> function when max_execution_time takes effect and the signal

Re: [PHP-DEV] request for comments on threadsafe / multi-thread enabled Embed2 SAPI

2009-03-26 Thread Moriyoshi Koizumi
Isn't it better to avoid any behaviour-changing #define's in a header file? I mean the following series of lines in php_embed2.h: /* we control char* lifetime of smart_str as we allow it to cross request boundaries */ #define SMART_STR_USE_REALLOC 1 /* we use bigger numbers than default as script

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h

2009-05-14 Thread Moriyoshi Koizumi
a number of crucial fixes and if your comments are > validated via user feedback we can adjust the values with 5.2.10 that can be > repackaged fairly rapidly. IMHO the current functionality is desired and is > acceptable. > > Ilia Alshanetsky > > > > > On 26-Feb-09, at 1:5

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/iconv iconv.c

2009-05-14 Thread Moriyoshi Koizumi
Ilia, do you still see any problem merging this to 5.2? Moriyoshi On Sat, Apr 11, 2009 at 6:16 PM, Hannes Magnusson wrote: > Ilia? > > I guess the chances of getting this merged Moriyoshi will increase by > 100% if you have a testcase.. > > -Hannes > > On Tue, Mar 17,

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h

2009-05-14 Thread Moriyoshi Koizumi
While I am stil wondering why we could not stop this kind of mess before the release, we should also revert the default for 5.3. There's no point making the behavior different between releases. Moriyoshi On Fri, May 15, 2009 at 5:10 AM, Andrei Zmievski wrote: > Ilia Alshanetsky wrote: >> >> Andr

Re: [PHP-DEV] Segfault while looping through hash table

2009-05-14 Thread Moriyoshi Koizumi
On Fri, May 15, 2009 at 12:31 PM, Farley Knight wrote: > zend_hash_internal_pointer_reset(Z_ARRVAL(zhash)); > > printf("This hash table has %d entries\n", > zend_hash_num_elements(Z_ARRVAL(zhash))); > > int current = 0; > > while (zend_hash_get_current_data(Z_ARRVAL(zhash), (void**)&value) >

[PHP-DEV] Alternative mbstring implementation using ICU

2009-07-26 Thread Moriyoshi Koizumi
Hi there, I almost finished an alternative implementation of mbstring that uses ICU instead of the exotic libmbfl in hope of replacing the current one for 5.4 (and possibly, 6.0.) Although there are admittingly some known incompatibilities that need extra libraries to resolve them besides a numbe

Re: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ext/gd/ libgd/gdft.c tests/bug48555.phpt tests/bug48732.phpt tests/bug48801.phpt

2009-07-27 Thread Moriyoshi Koizumi
Just to be sure, is there any consensus on this? I thought I should use svn merge. Moriyoshi On Tue, Jul 28, 2009 at 12:30 AM, David Soria Parra wrote: > On 2009-07-27, Takeshi Abe wrote: >> Log: >> MFH: fixed #48732 (TTF Bounding box wrong for letters below baseline) and >> #48801 (Problem wit

[PHP-DEV] Re: ext/iconv/tests/bug16069.phpt

2009-07-28 Thread Moriyoshi Koizumi
That is a test that is involved in the iconv's transilteration feature, the behavior of which may vary by the platform you use. I guess we don't actually need to test it then. Moriyoshi On Tue, Jul 28, 2009 at 12:27 PM, Rasmus Lerdorf wrote: > Moriyoshi, or someone who knows CP932 and EUC-JP, co

Re: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ext/gd/ libgd/gdft.c tests/bug48555.phpt tests/bug48732.phpt tests/bug48801.phpt

2009-07-28 Thread Moriyoshi Koizumi
Incorporating the changes and merges across the branches into one commit under a sparse-layouted local copy doesn't do the book-keeping against svn:mergeinfo. That's why I suppose it is not a good idea. Moriyoshi On Tue, Jul 28, 2009 at 7:44 AM, Gwynne Raskind wrote: > On Jul 27, 2009, at 6:31 P

[PHP-DEV] Re: Alternative mbstring implementation using ICU

2009-07-28 Thread Moriyoshi Koizumi
I set up a RFC page for this in wiki.php.net. Here it goes: http://wiki.php.net/rfc/altmbstring Moriyoshi 2009/7/26 Moriyoshi Koizumi : > Hi there, > > I almost finished an alternative implementation of mbstring that uses > ICU instead of the exotic libmbfl in hope of replacing the

[PHP-DEV] Re: Alternative mbstring implementation using ICU

2009-07-29 Thread Moriyoshi Koizumi
Aren't there any interests on this? If you think PHP 6 is gonna cover all of the functionality that allegedly-cruft mbstring currently provides, that is almost wrong :-p Moriyoshi On Tue, Jul 28, 2009 at 5:41 PM, Moriyoshi Koizumi wrote: > I set up a RFC page for this in wiki.php.net.

Re: [PHP-DEV] Alternative mbstring implementation using ICU

2009-07-31 Thread Moriyoshi Koizumi
On Thu, Jul 30, 2009 at 7:21 PM, Alexey Zakhlestin wrote: > 2009/7/26 Moriyoshi Koizumi : > >> - mb_ereg_search(), mb_ereg_search_getpos(), mb_ereg_search_getregs(), >>  mb_ereg_search_init(), mb_ereg_search_pos(), mb_ereg_search_regs() and >>  mb_ereg_search_setpos() >

Re: [PHP-DEV] Alternative mbstring implementation using ICU

2009-07-31 Thread Moriyoshi Koizumi
On Thu, Jul 30, 2009 at 8:05 PM, Niel Archer wrote: >> Implemented functions: >> >> - mb_ereg() >> - mb_ereg_replace() > > as ereg functions are deprecated in 5.3, are these still needed? mb_ereg_XXX() have nothing to do with the plain ereg functions. They are named so purely for the historical re

Re: [PHP-DEV] Re: Alternative mbstring implementation using ICU

2009-07-31 Thread Moriyoshi Koizumi
On Fri, Jul 31, 2009 at 2:37 AM, Stanislav Malyshev wrote: > Hi! > >> Aren't there any interests on this? If you think PHP 6 is gonna cover >> all of the functionality that allegedly-cruft mbstring currently >> provides, that is almost wrong :-p > > Could you please explain why PHP6 doesn't provide

Re: [PHP-DEV] Re: Alternative mbstring implementation using ICU

2009-07-31 Thread Moriyoshi Koizumi
On Fri, Jul 31, 2009 at 5:24 PM, Moriyoshi Koizumi wrote: >> mb_str* - shouldn't you in 6 just convert them to unicode and do all string >> operations with Unicode strings? Also, in 5 isn't there some intersection >> with grapheme_* functions? > > mb_strwidth() a

Re: [PHP-DEV] Re: Alternative mbstring implementation using ICU

2009-07-31 Thread Moriyoshi Koizumi
Hi, On Sat, Aug 1, 2009 at 1:37 AM, Stanislav Malyshev wrote: > Hi! > >>> mb_str* - shouldn't you in 6 just convert them to unicode and do all >>> string >>> operations with Unicode strings? Also, in 5 isn't there some intersection >>> with grapheme_* functions? >> >> mb_strwidth() and mb_strimwid

Re: [PHP-DEV] Re: Alternative mbstring implementation using ICU

2009-08-03 Thread Moriyoshi Koizumi
On Sat, Aug 1, 2009 at 9:02 AM, Stanislav Malyshev wrote: > Hi! > >> They calculate the total width of a string based on "east asian width" >> property, which is still valid to give a rough measurement of the >> rendered string. > > OK, I guess if it's some kind of special calculation that doesn't

Re: [PHP-DEV] Re: Alternative mbstring implementation using ICU

2009-08-03 Thread Moriyoshi Koizumi
On Tue, Aug 4, 2009 at 2:47 AM, Stanislav Malyshev wrote: >> And yes, it's worth providing separate conversion system.  You might >> not be aware of it, but there are several sets of different character >> sets, each of which is often represented with a specific encoding >> scheme.  Shift_JIS is o

[PHP-DEV] Re: [PHP-I18N] adding GB18030 support for mbstring

2010-01-31 Thread Moriyoshi Koizumi
Kitazaki-san, First thank you for your effort. But, I am under the impression that the conversion table looks too huge to include in a distribution (>30MB). Is there any way to get this more compressed? BTW, I created an extension that is near-compatible with mbstring and based on ICU that of co

Re: [PHP-DEV] adding GB18030 support for mbstring

2010-02-01 Thread Moriyoshi Koizumi
2010/2/1 KITAZAKI Shigeru : > * php_syslog.patch >  syslog() function cannot properly send UTF-8 strings to event log on >  Windows. This patch changes the internal API. We, however, must set >  UTF-8 on 'mbstring.internal_incoding'. >  In addition, this changes the severity of 'LOG_ERR' from event

Re: [PHP-DEV] PHP 6

2010-03-12 Thread Moriyoshi Koizumi
I'd love to see my brand-new mbstring implementation in the release. Dropping mbstring completely won't be any good because lots of applications rely on it, but I don't really want to maintain the funky library bundled with it. Moriyoshi On Fri, Mar 12, 2010 at 2:22 AM, Rasmus Lerdorf wrote: > A

Re: [PHP-DEV] PHP 6

2010-03-12 Thread Moriyoshi Koizumi
make a serious internaltionalized application. Moriyoshi On Sat, Mar 13, 2010 at 3:34 AM, Derick Rethans wrote: > On Fri, 12 Mar 2010, Hannes Magnusson wrote: > >> On Fri, Mar 12, 2010 at 17:38, Moriyoshi Koizumi wrote: >> > I'd love to see my brand-new mbstrin

Re: [PHP-DEV] PHP 6

2010-03-13 Thread Moriyoshi Koizumi
On Sat, Mar 13, 2010 at 8:09 PM, Lester Caine wrote: > Handling unicode CONTENT is not the problem here. People nowadays expect to > be able to use their own language to write code, and create functions using > words that they recognize. In databases, table and field names are now > expected to su

Re: [PHP-DEV] PHP 6

2010-03-13 Thread Moriyoshi Koizumi
On Sat, Mar 13, 2010 at 6:07 PM, Chen Ze wrote: > I think unicode should only care for string handling. Formatting > numbers should not be the thing that unicode cares. Unicode is a > standard for text, not for text or number formatting. > > Back to the days we don't have unicode, the number forma

Re: [PHP-DEV] PHP 6

2010-03-13 Thread Moriyoshi Koizumi
Surprisingly, It can be done quite easily with the current object handler infrastructure. Moriyoshi On Sun, Mar 14, 2010 at 12:08 AM, Pierre Joye wrote: > On Sat, Mar 13, 2010 at 3:13 PM, Moriyoshi Koizumi wrote: > >> I don't totally agree with what is being said here, but I

Re: [PHP-DEV] PHP 6

2010-03-13 Thread Moriyoshi Koizumi
It looks like I stripped off too much. Attached is the right one. Moriyoshi On Sun, Mar 14, 2010 at 12:41 AM, Moriyoshi Koizumi wrote: > Surprisingly, It can be done quite easily with the current object > handler infrastructure. > > Moriyoshi > > On Sun, Mar 14, 2010 at 12:

Re: [PHP-DEV] PHP 6

2010-03-13 Thread Moriyoshi Koizumi
On Sun, Mar 14, 2010 at 1:57 AM, Derick Rethans wrote: > - in the meanwhile, start working on patching in back Unicode support, >  but in small steps. Exactly which things, and how we'd have to find >  out. But I do think it needs to be a *core* language feature, and not >  simply solved by exten

Re: [PHP-DEV] Where are we ACTUALLY on Unicode?

2010-03-14 Thread Moriyoshi Koizumi
On Sun, Mar 14, 2010 at 11:23 PM, Jordi Boggiano wrote: > On Sun, Mar 14, 2010 at 12:03 PM, Stan Vassilev wrote: >> UTF8 also takes 4 bytes for representing characters in the higher bit >> planes, as quite a lot of bits are lost for every char in order to describe >> how long the code point is, a

Re: [PHP-DEV] Re: moving forward

2010-03-14 Thread Moriyoshi Koizumi
On Mon, Mar 15, 2010 at 6:25 AM, Herman Radtke wrote: >> Oh no .. another dangerous topic. Again we have been there even before the >> switch. The idea is to keep the centralized repo on svn, because the masses >> know how it works, the tools are widely available and we have plenty of >> experi

Re: [PHP-DEV] Performance improvements

2010-03-24 Thread Moriyoshi Koizumi
Hi, Wouldn't it suffice to add a field for the hash value and a flag that indicates its validity to zval instead of appending zend_literal everywhere? Moriyoshi On Wed, Mar 24, 2010 at 11:12 PM, Zeev Suraski wrote: > Hi, > > Over the last few weeks we've been working on several ideas we had for

  1   2   3   >