Hotfix: password_hasher catch block leaves its exception unreferenced

Table of Contents

This page documents a story in Sprint 25. It captures the goal, current status, acceptance criteria, and the tasks that compose it.

1. Goal

Restore the Windows MSVC build for ores.security. The catch block at password_hasher.cpp:127 discards the exception, so it must not name it.

2. Status

Field Value
State DONE
Parent sprint Sprint 25
Now Nothing.
Waiting on Nothing.
Next Nothing.
Last touched 2026-09-22

3. Acceptance

  • ores.security compiles on Windows MSVC with /WX and no C4101 warning.
  • The catch block still logs and returns false on a malformed scrypt parameter.

4. Tasks

Task State Start End Description
Scaffold story: Hotfix: password_hasher catch block leaves its exception unreferenced DONE 2026-09-22 2026-09-22 Story scaffolding rides this task: documents, sprint wiring, and the scaffold PR. Close it before merging that PR.
Implement Hotfix: password_hasher catch block leaves its exception unreferenced DONE   2026-09-22 Initial task for: Hotfix: password_hasher catch block leaves its exception unreferenced

5. Decisions

  • Drop the parameter name rather than add a cast-to-void or a suppression. The block never needed the exception, and catch (const std::exception&) is already the established form in this codebase, used by 44 catch clauses.
  • The whole source tree was checked for the same defect before the PR: 1371 catch (const std::exception& e) clauses across 394 files. This was the only one that never referenced e, so the fix stays a single line.

6. Out of scope

  • Enforcing the unnamed-catch form in CI or clang-tidy. The tree is already clean, so a rule would guard against a future regression rather than fix a present one.

7. Result

The Windows MSVC build failure for ores.security is fixed with a one-line change: password_hasher.cpp no longer names the exception it discards.

ores.security.lib builds green and ores.security.tests passes 127 assertions in 55 test cases. C4101 is MSVC-only, and Continuous Windows runs on a schedule rather than per pull request, so its next run is the first real MSVC check of this fix.

Emacs 29.3 (Org mode 9.6.15)