test: expand config file parsing coverage

[MohamedKamal000]

Closes #48

• String parsing edge cases

• Quoted values with spaces: api_key = "my key with spaces"

• Values with equals signs: api_key = "key=value=test"

• Empty quoted strings: api_key = ""

• Single quotes vs double quotes

• Comment handling

• Full-line comments: # This is a comment
  (already was being covered)

• Inline comments: api_key = "key" # my key

• Comment characters inside quotes: message = "use # for comments"

• Section handling

• Unknown sections (should be ignored or error?)
  (i decided to ignore it with a warning)

• Duplicate sections
  (i decided so that any appearance of the same key would override the old one, might need docs changes if not specified)

• Keys outside any section
  (keys outside a section or inside a wrong section will be ignored with a warning)

• Boolean parsing
  (i made it so that any invalid boolean value would default to false with a warning)

• Error handling

• Missing config file
  (it was already covered in different test)

• Permission denied
  (i'm not really sure how to cover this, i thought about calling something like chmod but i think it would be os dependent, another solution would be implementing mocking but this would require more refactoring)

• Malformed lines
  (i have made a regex that checks for INI style format so i can handle all cases easily)

• Very long lines
  ( added a constant for max line length, not sure which value exactly should i choose for this)

Notes

• i can change the config documentation if the current changes is accepted
• i have noticed that there is some repeated sections of the config code, i don't mind to take more time to refactor it

[benodiwal]

/claude

[github-actions]

Claude finished @benodiwal's task in 1m 42s —— View job

---

Code Review Complete ✅

Great work expanding the test coverage for config file parsing! The PR significantly improves robustness in handling edge cases. Here's my detailed review:

---

Strengths

1. Comprehensive test coverage - All the edge cases mentioned in the PR description are well covered
2. Good error handling - Proper validation for malformed lines, long lines, and invalid sections
3. Flexible boolean parsing - Supporting multiple boolean variants (true/false, yes/no, 1/0) is user-friendly
4. Single/double quote support - Both quote styles work correctly

---

Issues Found

1. Operator Precedence Bug in Quote Detection ⚠️

Location: src/config.cpp:200

if (value.length() >= 2 && value[0] == '"' || value[0] == '\'') {

This is a critical bug. Due to operator precedence, this evaluates as:

if ((value.length() >= 2 && value[0] == '"') || value[0] == '\'') {

This means single quotes will be matched even for strings of length 1, potentially causing out-of-bounds access when looking for the closing quote. For example, a value of just ' would match this condition and then try to find a closing quote at position 1, which doesn't exist.

Fix: Add explicit parentheses:

if (value.length() >= 2 && (value[0] == '"' || value[0] == '\'')) {

Fix this →

---

2. Inconsistent Handling of Unclosed Quotes

Location: src/config.cpp:202-211

Currently, if a quote is not closed properly, the code silently keeps the malformed value. For example:

api_key = "unclosed quote

This would set api_key to an empty string (or malformed value) without any error or warning.

Recommendation: Add explicit validation for unclosed quotes and log a warning:

if (value[0] == '"') {
  size_t closing_quote = value.find('"', 1);
  if (closing_quote != std::string::npos) {
    value = value.substr(1, closing_quote - 1);
  } else {
    logger::Logger::warning("Unclosed double quote in value: " + key);
    // Either use the malformed value as-is, or skip this key
  }
}

---

3. Regex Pattern May Be Too Restrictive

Location: src/config.cpp:370-371

std::regex kv_pattern(
    R"lit((^\s*([a-zA-Z0-9_]+)\s*=\s*((?:"([^"]*)")|(?:'([^']*)')|(?:([^\s'"]*)))(\s*#.*)?))lit");

Issues:

• The pattern requires that unquoted values have no spaces: (?:([^\s'"]*)) - this is good for validation
• However, it doesn't allow for unquoted values that contain certain special characters users might expect to work (like dots in URLs without quotes)
• The regex doesn't handle escaped quotes inside quoted strings (e.g., "value with \" inside")

Consideration: Document this restriction clearly in the configuration documentation that unquoted values cannot contain spaces or special characters, and must use quotes for complex values.

---

4. MAX_CONFIG_LINE_LENGTH Value Lacks Justification

Location: src/include/config.hpp:42

constexpr int MAX_CONFIG_LINE_LENGTH = 8192;

As noted in the PR description, the author is uncertain about this value. Some considerations:

• 8KB is reasonable for most config files, but consider if users might have very long API keys or base64-encoded credentials
• Most INI parsers use 8KB-32KB limits
• Consider making this configurable or at least document why this limit exists

Recommendation: Add a comment explaining the rationale and consider bumping to 16KB for safety:

// Maximum config line length to prevent memory exhaustion attacks
// 16KB should accommodate long API keys and base64-encoded values
constexpr int MAX_CONFIG_LINE_LENGTH = 16384;

---

5. Potential Performance Issue with Vector Iteration

Location: src/config.cpp:354-367

bool ConfigManager::isValidSection(const std::string& section) {
  std::vector<std::string> keys = {
      constants::SECTION_RESPONSE, constants::SECTION_QUERY,
      constants::SECTION_GENERAL,  constants::SECTION_GEMINI,
      constants::SECTION_OPENAI,   constants::SECTION_ANTHROPIC,
  };

  for (const auto& key : keys) {
    if (key == section)
      return true;
  }
  return false;
}

Issues:

• Creates a new vector on every call (this function is called twice per line in some cases)
• Linear search through 6 elements isn't terrible, but could be better

Recommendation: Make this a static constant or use a set for O(1) lookup:

bool ConfigManager::isValidSection(const std::string& section) {
  static const std::unordered_set<std::string> valid_sections = {
      constants::SECTION_RESPONSE, constants::SECTION_QUERY,
      constants::SECTION_GENERAL,  constants::SECTION_GEMINI,
      constants::SECTION_OPENAI,   constants::SECTION_ANTHROPIC,
  };
  return valid_sections.count(section) > 0;
}

---

6. Boolean Parsing Has Similar Performance Issue

Location: src/config.cpp:375-396

The parseBooleanValue function creates two new vectors on every call. Same recommendation as above - use static constants:

bool ConfigManager::parseBooleanValue(const std::string& value) {
  static const std::unordered_set<std::string> true_values = {"true", "yes", "1"};
  static const std::unordered_set<std::string> false_values = {"false", "no", "0"};
  
  std::string value_toLower = value;
  std::transform(value_toLower.begin(), value_toLower.end(),
                 value_toLower.begin(), ::tolower);
  
  if (true_values.count(value_toLower)) return true;
  if (false_values.count(value_toLower)) return false;
  
  logger::Logger::warning("Invalid Boolean Value, Got: " + value +
                          " instead, falling back to false");
  return false;
}

---

7. Typo in Test Name

Location: tests/unit/test_config.cpp:470

TEST_F(ConfigManagerTest, HandlesDublicateSections) {

Should be HandlesDuplicateSections (duplicate, not "dublicate")

---

Code Style Issues

1. Inconsistent brace style (line 200): The if-else chain should follow the same bracing style throughout
2. Variable naming (line 376): value_toLower should be value_to_lower or valueLower to match C++ conventions
3. Missing const-correctness (line 383, 388): Loop variables could be const auto& instead of auto&

---

Test Coverage Suggestions

While the test coverage is excellent, consider adding tests for:

1. Mixed quote types - What happens with mismatched quotes like api_key = "value'?
2. Escaped quotes - How should api_key = "value with \" quote" be handled?
3. Multiple hash symbols - Does api_key = value # comment # more work correctly?
4. Whitespace in sections - What about [ openai ] with spaces?
5. Empty sections - What if a section header is just []?
6. Unicode characters - What happens with non-ASCII characters in values?
7. Line ending variations - CRLF vs LF (Windows vs Unix)

---

Documentation Needs

As you mentioned in the PR description, documentation updates would be valuable:

1. Document the line length limit and why it exists
2. Document that duplicate sections merge (last value wins)
3. Document that unknown sections are ignored with warnings
4. Document the regex validation rules (unquoted values can't have spaces)
5. Document supported boolean variants
6. Document quote escaping behavior (or lack thereof)

---

Refactoring Suggestions

You mentioned noticing repeated code sections. Here are the main candidates:

1. Provider config parsing (lines 256-321): The OpenAI, Anthropic, and Gemini sections have nearly identical logic. Consider extracting a helper function:

   void parseProviderSection(const std::string& key, const std::string& value, 
                             Provider provider, const std::string& default_model);

2. Quote extraction logic: The double/single quote extraction (lines 201-211) could be a helper function

---

Security Considerations

1. ✅ Good: Maximum line length prevents memory exhaustion
2. ✅ Good: Regex validation prevents injection attacks
3. ⚠️ Consider: Log messages contain user input - ensure the logger sanitizes output to prevent log injection
4. ⚠️ Consider: The regex compilation happens on every isValidLine call - move it to a static variable for performance and safety

---

Summary

Critical Issues:

• Operator precedence bug at line 200 (must fix)

Important Issues:

• Performance issues with vector creation (should fix)
• Unclosed quote handling (should add warning)
• Test name typo (minor but should fix)

Nice to Have:

• Better test coverage for edge cases
• Documentation updates
• Code refactoring for DRY principle
• Increased line length limit with documentation

The PR is solid and adds valuable test coverage. The critical operator precedence bug should be fixed before merging, and the performance optimizations are recommended. After addressing the critical bug, this will be a great improvement to the codebase!

---

Tasks

• Read project guidelines (CLAUDE.md)
• Review the PR diff
• Analyze config.cpp changes
• Analyze config.hpp changes
• Review test coverage and quality
• Provide comprehensive feedback

---

[MohamedKamal000]

• 1. Operator Precedence Bug in Quote Detection
• 2. Inconsistent Handling of Unclosed Quotes
• i don't think it will even reach this point, since the regex validates, but i added the warning anyway
• 3. Regex Pattern May Be Too Restrictive
• i added quotes escaping, it works only with quotes, any other thing like "\n" for example will be literally included
• 4. MAX_CONFIG_LINE_LENGTH Value Lacks Justification
• 5. Potential Performance Issue with Vector Iteration
• 6. Boolean Parsing Has Similar Performance Issue
• 7. Typo in Test Name

Code Style Issues
i ran make format, shouldn't that format it ?

Test Coverage Suggestions

• Mixed quote types - What happens with mismatched quotes like api_key = "value'?
• i added a test coverage for this, this should not be parsed and will result in error
• Escaped quotes - How should api_key = "value with " quote" be handled?
• i added quotes escaping, something like this will be "value with " quote"
• Multiple hash symbols - Does api_key = value # comment # more work correctly?
• i think the correct result of this will be "value", i covered this case as well
• Whitespace in sections - What about [ openai ] with spaces?
• i think sections should exactly match what is specified, this case will result in a warning to the user
• Empty sections - What if a section header is just []?
• Unicode characters - What happens with non-ASCII characters in values?
• currently Unicode characters can be parsed normally,
  but i don't know if there is a scenario the user would need to write a Unicode character in the config file
• Line ending variations - CRLF vs LF (Windows vs Unix)
• i removed any CR that exists

Documentation Needs
Done

Refactoring Suggestions
Done

Security Considerations

• Log messages contain user input - ensure the logger sanitizes output to prevent log injection
• How can this result in injection if the log message itself is just writen in a log file without any query execution ?
  is this really needed ?
• The regex compilation happens on every isValidLine call - move it to a static variable for performance and safety

let me know if anything else needed @benodiwal