From: Gerhard Sittig <redacted>
Date: Mon, 5 Jun 2017 17:33:42 +0000 (+0200)
Subject: input/csv: Update developer comment (fix for last EOL marker)
X-Git-Tag: libsigrok-0.5.0~13
X-Git-Url: https://sigrok.org/gitweb/?a=commitdiff_plain;h=de788af4108493211d2c62004bf3d2fd81ad7d67;p=libsigrok.git

input/csv: Update developer comment (fix for last EOL marker)
---

diff --git a/src/input/csv.c b/src/input/csv.c
index ab22f075..1d230fdc 100644
--- a/src/input/csv.c
+++ b/src/input/csv.c
@@ -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