Feature Request/Design Issue on FGETCSV

getcsv  i..e fgetcsv without the file read would be very useful, fgetcsv as it is isn't much use.

At least two reasons:

1. Line terminator, depending on Mac, PC, Unix origin the line terminator could be \r,\n,\r\n.  This is not too hard to cope with via a fgets and an explode on \r.  But then I can't use fgetcsv to do the parsing since it insists for some bizarre reason, on doing the file read itself. 

This could be solved by an optional line terminator argument to fgetcsv, as long as it's a regular expression, but it's all extra complication for all the default behaviour users.

2. Acquiring the original, unparsed line.  Typically, if a line of an uploaded csv file fails my own validation I want to just chuck the line back via a "rejects" download.  This is easy if I have the original line read in its original format but a pain if I just have the parsed version and have to put back the comma-separation all over again.  I can't even guarantee to return the original line since I don't know if the fields were quoted or not!

Practically this makes fgetcsv useless for me, simply because it does TOO MUCH i.e. it insists on doing the file read rather than just the parsing!

My preferred solution would have just been to have getcsv accepting a
string,  then fgetcsv would be simply coded as  getcsv(fgets($fp...))

As we've got fgetcsv now, I guess we gotta keep it, but can we also have getcsv please!

Many thanks,

George

P.S. On a more general note, I hope we aren't going to start having php following the Microsoft pseudo-intelligent style of trying to bundle too much into each function.   We want tools, not someone else's solutions to what they think our problem is!