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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
