Thanks for your keen eye @Girgias.

I don't know if this needs an RFC or not

I was going to ask about that in my original post. I suppose we can wait for some opinions :)

IMHO it's bad to add more paramters to fputcsv() (especially wrt. $escape_character which was a bad idea in the first place). Anyhow, I suggest to write to the internals mailing list for better visibility.

If you are adding this extra parameter on fputcsv wouldn't it be more appropriate to make sure fgetcsv and it's implementation in SplFileObject gets the same treatment which means adding the functionality also when reading a csv 🤔.
I also share the concern expressed by @cmb69 we are adding maybe to many parameters to fput/fget(csv)

If you are adding this extra parameter on fputcsv wouldn't it be more appropriate to make sure fgetcsv and it's implementation in SplFileObject gets the same treatment which means adding the functionality also when reading a csv

fgetcsv() already happily accepts either LF or CRLF (can be even mixed for a single file). :)

I also share the concern expressed by @cmb69 we are adding maybe to many parameters to fput/fget(csv)

A counterpoint to this would be that PHP8 will introduced named arguments so developers could well do

<?php

$resource = fopen('file.csv', 'w');
$fields = ['aaa', 'bbb', 'ccc', 'dddd'];
$endOfLine = "\r\n";

fputcsv( handle: $resource, fields: $fields, eol: $endOfLine);

Not my favorite thing but named arguments could reduce the issue 🤔

Thanks for your responses everyone :)

As @cmb69 suggested, I've emailed internals[1] to see if we can get any further input from the community/team. I'm merely stating this for reference, and it's not an attempt to hurry things along - I'm content with things moving at their own pace :)

[1] https://externals.io/message/112248

Might make more sense to use a zend_string * instead of a char* although inconsistent with the rest of the API it does make using a NUL byte for the EOL sequence possible (and also add a test for that)

Thanks @Girgias. Would you mind teaching me how to do that? I tried working with zend_string initially but had a lot of trouble.

Thanks @Girgias. Would you mind teaching me how to do that? I tried working with zend_string initially but had a lot of trouble.

Did you have a look at https://www.phpinternalsbook.com/php7/internal_types/strings/zend_strings.html ? Otherwise follow-up by email. :-)

Looks rather good, but still don't know if the list is going to be more responsive now.

I'll bump the list one more time, but perhaps this is a lost cause and I should shift my focus to your ext-csv and then RFC that into the core - assuming that's your plan?

Looks rather good, but still don't know if the list is going to be more responsive now.

I'll bump the list one more time, but perhaps this is a lost cause and I should shift my focus to your ext-csv and then RFC that into the core - assuming that's your plan?

I would expect this to take longer as a process for ext-csv to be accepted as a bundled extension, so if nobody replies (other than me) I'll take it that we can merge this as a convenience.

I don't really know whether I like this change or not. Following a standard which is informational only (and seriously underspecified anyway) per se is not a good argument. That some software may require CRLF is, though. Still, I don't like the additional parameter, and adding it will make it harder to get rid of $escape_char, but that may not happen ever, so …

I don't really know whether I like this change or not. Following a standard which is informational only (and seriously underspecified anyway) per se is not a good argument. That some software may require CRLF is, though. Still, I don't like the additional parameter, and adding it will make it harder to get rid of $escape_char, but that may not happen ever, so …

I mean that's one reason why I went and started from scratch, if there was a way to specify that this can only be used as a named param this would allow us to drop $escape_char whenever we want, but I don't think we have any thing of that sort?

The point is rather that some may rely on that $escape_char stuff, so removal may face resistance. It may indeed be better to introduce an alternative, such as ext/csv.

Thanks @Girgias all done 😄

This most probably is not the right place, anymore But the RFC 4180 specifies

2. The last record in the file may or may not have an ending line
   break.

I ran in a problem where a upstream system specifically did not accept a record separator after the last record and I ended up programming the fputcsv in php. I would be swell to have a flag to omit the last record separator.