From cb314a8b4c7a127a3316af60948dbc453f360b1b Mon Sep 17 00:00:00 2001 From: Robert Garrett Date: Thu, 17 Jul 2025 13:29:25 -0500 Subject: [PATCH] Assert empty conf str is an error, TODO: semantics The empty configuration string is some kind of an error, but I'm not sure where and how to handle it. It should be treated as a soft error, where I fall back to some hardcoded defaults. There's a logic hole at the moment: The error I'm actually getting right now is "NoSuchTable" because the "[all]" table doesn't exist. For a totally empty config file, the above response should be used. But what about a non-empty conf file? Is a missing "[all]" valid or not? For now, assert the loader returns *an* error and leave behind a TODO for later. --- src/config.rs | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/config.rs b/src/config.rs index 6f785bd..f6df0c7 100644 --- a/src/config.rs +++ b/src/config.rs @@ -242,4 +242,18 @@ repo = \"rcalc\" assert_eq!(conf, fx_expected_struct); Ok(()) } + + /* TODO: Improve semantics around reading an empty string + An empty config string will result in Error::NoSuchTable when "[all]" + is retrieved. But this will *also* happen when other configs are present, + but "[all]" isn't. Do I treat these as valid configurations, using some + hard-coded default as the fallback? Or do I reject configs that don't have + an all-table? + */ + #[test] + fn read_config_string_empty() { + let fx_sample_cfg = ""; + let conf = lconf(fx_sample_cfg); + assert!(conf.is_err()); + } }