+ return SR_OK;
+}
+
+/**
+ * @brief Parse routine which ignores the input text.
+ *
+ * This routine exists to unify dispatch code paths, mapping input file
+ * columns' data types to their respective parse routines.
+ */
+static int parse_ignore(const char *column, struct context *inc,
+ const struct column_details *details)
+{
+ (void)column;
+ (void)inc;
+ (void)details;
+ return SR_OK;
+}
+
+typedef int (*col_parse_cb)(const char *column, struct context *inc,
+ const struct column_details *details);
+
+static const col_parse_cb col_parse_funcs[] = {
+ [FORMAT_NONE] = parse_ignore,
+ [FORMAT_BIN] = parse_logic,
+ [FORMAT_OCT] = parse_logic,
+ [FORMAT_HEX] = parse_logic,
+ [FORMAT_ANALOG] = parse_analog,
+ [FORMAT_TIME] = parse_timestamp,
+};
+
+/*
+ * BEWARE! Implementor's notes. Sync with feature set and default option
+ * values required during maintenance of the input module implementation.
+ *
+ * When applications invoke .format_match() routines, trying automatic
+ * determination of an input file's format handler, then no options are
+ * in effect. Because specifying options requires selection of an input
+ * module to pass the options to, which obsoletes the format-match check.
+ *
+ * Which means that we only need to deal with the default format here,
+ * which happens to be the simple multi-column format without header
+ * lines or leading garbage. Which means that the check can be rather
+ * strict, resulting in high levels of confidence upon match, never
+ * "accidently" winning for unreadable or unsupported-by-default formats.
+ *
+ * This .format_match() logic only needs to become more involved when
+ * default option values change, or when automatic detection of column
+ * data types improves. Then the supported-by-default types of input
+ * data must be considered acceptable here in the format-match check
+ * as well.
+ *
+ * Notice that the format check cannot re-use regular processing logic
+ * when their implementation assumes proper input data and wll generate
+ * diagnostics for unexpected input data. Failure to match the format is
+ * non-fatal here, mismatch must remain silent. It's up to applications
+ * how large a chunk of data gets passed here (start of the file's
+ * content). But inspection of the first few hundred bytes will usually
+ * be GoodEnough(TM) for the format-match purpose. Notice that filenames
+ * need not necessarily be available to the format-match routine.
+ *
+ * This implementation errs on the safe side. Users can always select
+ * the CSV input module when automatic format detection fails.
+ */
+static int format_match(GHashTable *metadata, unsigned int *confidence)
+{
+ const int match_confidence = 100;
+ const char *default_extension = ".csv";
+ const char *line_termination = "\n";
+ const char *comment_leader = ";";
+ const char *column_separator = ",";
+ const char *binary_charset = "01";
+
+ const char *fn;
+ GString *buf;
+ size_t fn_len;
+ GString *tmpbuf;
+ gboolean status;
+ size_t line_idx, col_idx;
+ char *rdptr, **lines, *line;
+ char **cols, *col;
+
+ /* Get the application provided input data properties. */
+ fn = g_hash_table_lookup(metadata, GINT_TO_POINTER(SR_INPUT_META_FILENAME));
+ buf = g_hash_table_lookup(metadata, GINT_TO_POINTER(SR_INPUT_META_HEADER));
+
+ /* Filenames are a strong hint. Use then when available. */
+ if (fn && *fn && (fn_len = strlen(fn)) >= strlen(default_extension)) {
+ if (strcasecmp(&fn[fn_len - strlen(default_extension)], default_extension) == 0) {
+ *confidence = 10;
+ return SR_OK;
+ }