Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:6378 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 6454 invoked by uid 1010); 12 Dec 2003 22:17:30 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 6426 invoked from network); 12 Dec 2003 22:17:29 -0000 Received: from unknown (HELO asuka.nerv) (24.112.18.98) by pb1.pair.com with SMTP; 12 Dec 2003 22:17:29 -0000 Received: (qmail 5448 invoked from network); 12 Dec 2003 17:12:39 -0000 Received: from rei.nerv (HELO dummy.com) (rei@192.168.1.1) by asuka.nerv with SMTP; 12 Dec 2003 17:12:39 -0000 Reply-To: ilia@prohost.org Organization: Prohost.org To: Moriyoshi Koizumi , PHP Internals Date: Fri, 12 Dec 2003 17:28:44 -0500 User-Agent: KMail/1.5.4 References: <25BBBBC2-2CD2-11D8-8FCC-000A95CE0C62@at.wakwak.com> <200312121551.25399.ilia@prohost.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <200312121728.44466.ilia@prohost.org> Subject: Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch) From: ilia@prohost.org (Ilia Alshanetsky) On December 12, 2003 04:18 pm, Moriyoshi Koizumi wrote: > I disagree, because of the following reasons: > > 1) Not a few people *actually* use fgetcsv() commonly > with multibyte characters indeed. Regarding this, > applications made by those who don't use > such characters don't (and won't) use multibyte specific > functions and that's the problem. This greatly prevents > them from being portable. People have lived without multibyte support in fgetcsv() for many years now, and I did not see a single request on bugs.php.net for fgetcsv() multi-byte support. So, while this is certainly useful functionality I do not believe it is as widely needed as you say it is. We also have a multibyte extension that already implements multi-byte safe variants of common functions, why make exception for fgetcsv() and add multibyte code into core? > 2) IMO speed is not a key factor here. People rather wants > trust-worthy behaviour. When it's a few percent and the changes offer significant improvements yes, but when were are talking about a performance loss of 250-300% or more then performance must become a consideration as well. > 3) fgetcsv() implementation in the stable branch is > now too complicated to add a new feature to > and also hard to maintain. We should be able to > eliminate the mblen() calls for acceptable performance. > See the attached result. What features are we talking about here? The only 2 features I can see we may wish to add are >1 char long enclosures and separators and the binary thing. Both of these features would be fairly trivial to add. > p.s. fgetcsv() in the stable branch still seems to segfault with > the attached test case (segfault.php.txt). Writing a fix now, thanks for the heads-up. If you have any more please let me know.