input/csv: Add developer comment with TODO items

[libsigrok.git] / src / input / csv.c

diff --git a/src/input/csv.c b/src/input/csv.c
index 5585b0eeacc07247aca5a34056d475cbf4c4a298..013d7a476b3338b6b14e993e8989b78019c371b7 100644 (file)
--- a/src/input/csv.c
+++ b/src/input/csv.c
@@ -67,6 +67,45 @@
  *                than 0. The default line number to start processing is 1.
  */
 
+/*
+ * TODO
+ *
+ * - Determine how the text line handling can get improved, regarding
+ *   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.
+ *   - 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
+ *     for CRLF (Windows) as well as LF (Unix), and allow for correct
+ *     line number counts.
+ *   - When support for CR-only line termination cannot get dropped,
+ *     then the current implementation is inappropriate. Currently the
+ *     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.
+ *   - 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
+ *     with more platforms or generators, then the current approach of
+ *     splitting on runs of termination characters needs to get replaced,
+ *     by the more expensive approach to scan for and count the initially
+ *     determined termination sequence.
+ *
+ * - Add support for analog input data? (optional)
+ *   - Needs a syntax first for user specs which channels (columns) are
+ *     logic and which are analog. May need heuristics(?) to guess from
+ *     input data in the absence of user provided specs.
+ */
+
 /* Single column formats. */
 enum {
        FORMAT_BIN,
@@ -644,12 +683,20 @@ static int process_buffer(struct sr_input *in)
        else
                max_columns = 1;
 
+       /*
+        * Consider empty input non-fatal. Keep accumulating input until
+        * at least one full text line has become available. Grab the
+        * maximum amount of accumulated data that consists of full text
+        * lines, and process what has been received so far, leaving not
+        * yet complete lines for the next invocation.
+        */
+       if (!in->buf->len)
+               return SR_OK;
        p = g_strrstr_len(in->buf->str, in->buf->len, inc->termination);
        if (!p)
-               /* Don't have a full line. */
                return SR_ERR;
-
        *p = '\0';
+       p += strlen(inc->termination);
        g_strstrip(in->buf->str);
 
        ret = SR_OK;
@@ -718,7 +765,7 @@ static int process_buffer(struct sr_input *in)
                g_strfreev(columns);
        }
        g_strfreev(lines);
-       g_string_erase(in->buf, 0, p - in->buf->str + 1);
+       g_string_erase(in->buf, 0, p - in->buf->str);
 
        return ret;
 }