input/csv: Update developer comment (fix for last EOL marker)
This commit is contained in:
parent
7f4c3a6224
commit
de788af410
|
@ -74,11 +74,7 @@
|
|||
* all of robustness and flexibility and correctness.
|
||||
* - The current implementation splits on "any run of CR and LF". Which
|
||||
* translates to: Line numbers are wrong in the presence of empty
|
||||
* lines in the input stream.
|
||||
* - The current implementation insists in the presence of end-of-line
|
||||
* markers on _every_ line in the input stream. "Incomplete" text
|
||||
* files that are so typical on the Windows platform get rejected as
|
||||
* invalid.
|
||||
* lines in the input stream. See below for an (expensive) fix.
|
||||
* - Dropping support for CR style end-of-line markers could improve
|
||||
* the situation a lot. Code could search for and split on LF, and
|
||||
* trim optional trailing CR. This would result in proper support
|
||||
|
@ -89,9 +85,7 @@
|
|||
* input stream is scanned for the first occurance of either of the
|
||||
* supported termination styles (which is good). For the remaining
|
||||
* session a consistent encoding of the text lines is assumed (which
|
||||
* is acceptable). Potential absence of the terminator for the last
|
||||
* line is orthogonal, and can get handled by a "force" flag when
|
||||
* the end() routine calls the process_buffer() routine.
|
||||
* is acceptable).
|
||||
* - When line numbers need to be correct and reliable, _and_ the full
|
||||
* set of previously supported line termination sequences are required,
|
||||
* and potentially more are to get added for improved compatibility
|
||||
|
|
Loading…
Reference in New Issue