Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100744
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain dqxtech.net from 209.85.215.48 cause and error)
MIME-Version: 1.0
In-Reply-To: <CA+kxMuQRHq8HfuicqSFm8_Xcxw7VD6Aaqoi5TZa7m7Tofh1YKA@mail.gmail.com>
References: <7cf5adb8-0738-259e-6d1e-f966722fdae2@gmx.de> <CA+kxMuQRHq8HfuicqSFm8_Xcxw7VD6Aaqoi5TZa7m7Tofh1YKA@mail.gmail.com>
Date: Fri, 22 Sep 2017 02:39:48 +0200
Message-ID: <CAH0Uv3F7vtDRivYjEOd+Xcrqssxjn6AiNhnsX6RqhwdUax3sVQ@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>
Cc: "Christoph M. Becker" <cmbecker69@gmx.de>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] fputcsv() and $escape character
From: andreas@dqxtech.net (Andreas Hennings)

On Thu, Sep 21, 2017 at 11:08 PM, Dan Ackroyd <danack@basereality.com> wrote:
> On 21 September 2017 at 12:43, Christoph M. Becker <cmbecker69@gmx.de> wrote:
>> Hi everybody!
>>
>> There are several bug reports regarding "broken" fputcsv() behavior in
>> our tracker, namely, because the $escape parameter causes unexpected
>> results.  For instance:
>
>
> I looked at fixing some of the CSV related bugs about a year or so
> ago. My conclusions were:
>
> i) There is no way to fix the problems that wouldn't cause horrible BC
> breaks for code that is only coincidentally working currently.

How so?
What we can do:
If $escape_char !== '', fputcsv() should work exactly as it does now.
It can even use the same C code.
If $escape_char === '', fputcsv() will have a different behavior than
currently, where no character is treated as special.

If we want to be 100% sure, these two cases can use completely
separate C code, with one if() at the entry point.

>
> ii) Handling strings in C is much more error prone than handling them in PHP.
>
> I'm reasonably certain that trying to fix the current functions is the
> wrong approach, and one of the following would be much better.
>
> Either, find a C library that has already been proven to handle CSV
> parsing/generating 'correctly' and bring that into PHP core under
> either new function names or namespace.

Yeah why not. But it will require a lot more work and design decisions
than just introducing a new allowed value for $enclosure parameter.

>
> Or, write the code in PHP (or just use
> https://github.com/thephpleague/csv) and find a way to make that fast
> enough for people to use.

It can never be as fast as native functions.
I vaguely remember something like factor 2 or 3 when I tried it, but
for now treat this as hearsay.

>
> Touching the existing code is pretty certain to bring a lot of pain,
> without resulting in a fully compliant csv parser/generator.
>
> cheers
> Dan
> Ack
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>