Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:6362
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <25BBBBC2-2CD2-11D8-8FCC-000A95CE0C62@at.wakwak.com>
Content-Transfer-Encoding: 7bit
Cc: PHP Internals <internals@lists.php.net>
Date: Sat, 13 Dec 2003 03:36:49 +0900
To: ilia@prohost.org
Subject: Regarding the latest patch on fgetcsv() (stable branch)
From: moriyoshi@at.wakwak.com (Moriyoshi Koizumi)

Hi Ilia,

During the verification of bug #26600, I just noticed
fgetcsv() now behaves differently than the previous release 4.3.4.

After a quick examination, I found the change you made
on r-1.279.2.41 is related to this issue.

http://cvs.php.net/diff.php/php-src/ext/standard/file.c? 
r1=1.279.2.41&r2=1.279.2.42&ty=h

Before the patch, the test case attached below had given the
following result:

array(3) {
   [0]=>
   string(1) "a"
   [1]=>
   string(1) "b"
   [2]=>
   string(1) "c"
}

Since it was patched, fgetcsv() returns the following:

array(3) {
   [0]=>
   string(1) "a"
   [1]=>
   string(2) " b"
   [2]=>
   string(2) " c"
}

While I think the new behaviour is consistent with the CSV format
used by Microsoft Excel, it'd be a BC problem also.

Test case:
<?php
$file = '/tmp/test.csv';
$fp = fopen($file, 'w');
fwrite($fp, "a, b, c\n");
fclose($fp);
$fp = fopen($file, 'r');
var_dump(fgetcsv($fp, filesize($file)));
fclose($fp);
?>

What do you think of this?

Moriyoshi