Version 2.4.1: CSV Parser Bulletproofing

[vincentlaucsb]

• Fixes Debug builds on linux always link against gcov #279 by disabling gcov by default
• Fixes numerous address and thread safety issues with lock-free design
  • Replaced std::deque with fixed-size atomic block pointer table in CSVFieldList to prevent heap-use-after-free from internal map reallocation
  • CSVRow::iterator now captures shared_ptr to data, preventing use-after-free when row is reassigned
  • ThreadSafeDeque hot paths (empty(), is_waitable()) now lock-free with atomic flags
    • Removed unnecessary locks from notify_all()/kill_all()
  • Added iterator semantics documentation warning against forward-iterator algorithms
• Made CSVField hex parsing templated
  • Does not break existing int usages
  • Now defaults to long long for increased overflow safety
• Added ASan/TSan to GitHub CI/CD

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

In general, the fix is to explicitly set a restrictive permissions block in the workflow, ideally at the top level so it applies to all jobs, and only broaden it if/when a specific job needs more. For this workflow, the jobs only need to read repository contents and interact with artifacts; they do not need to write to code, PRs, or issues. A suitable minimal configuration is permissions: contents: read, which still allows actions/checkout to function, and does not interfere with actions/upload-artifact (which does not use GITHUB_TOKEN).

The single best fix without changing functionality is to add a top-level permissions section right under the name: (and before on:) that sets contents: read. This will apply to both sanitizers and valgrind jobs, satisfying CodeQL and enforcing least privilege. No other code, steps, or jobs need modifications, and no imports or external libraries are involved since this is a YAML configuration change only.

Specifically, in .github/workflows/sanitizers.yml, insert:

permissions:
  contents: read

between line 1 (name: Memory and Thread Sanitizers) and line 3 (on:). No other file changes are required.

In general, to fix this issue you should explicitly declare permissions for the GITHUB_TOKEN either at the workflow root (applying to all jobs) or for each job individually, granting only the minimal scopes needed. For a build-and-test workflow that only checks out the repo and uploads artifacts, contents: read is typically sufficient.

The best, least-invasive fix here is to add a single root-level permissions block right under the name: (or under on:) in .github/workflows/sanitizers.yml. This will apply to both sanitizers and valgrind jobs and ensures that the GITHUB_TOKEN has read-only access to repository contents and no write scopes. No existing steps need modification, and no new dependencies or imports are required, because GitHub Actions interprets the permissions key natively.

Concretely:

• Edit .github/workflows/sanitizers.yml.
• Insert:

permissions:
  contents: read

after the name: Memory and Thread Sanitizers line (or equivalently between on: and jobs:), ensuring indentation matches YAML rules (root-level, no extra spaces). This documents and enforces least-privilege access for the workflow.