fix: make the JSONCPP_USE_SECURE_MEMORY build compile and pass

[lenamonj]

JSONCPP_USE_SECURE_MEMORY=1 does not build. It fails in three separate ways, each hidden behind the previous one, so fixing only the first gets you to the second. No CI job builds this configuration, which is how they accumulated.

Reproduce on master (60de77f), MSVC 19.44 x64:

cmake -S . -B sb -A x64 -DCMAKE_CXX_FLAGS="/DJSONCPP_USE_SECURE_MEMORY=1 /std:c++17"
cmake --build sb --config Debug

include\json\allocator.h(47,5): error C3861: 'RtlSecureZeroMemory': identifier not found

1. The _WIN32 branch calls RtlSecureZeroMemory without including <windows.h>. Removing that branch lets the portable volatile std::fill_n path handle Windows too. The same fill was zeroing n bytes rather than n * sizeof(T); Json::String is SecureAllocator<char> so it is unaffected, but any wider T through the public Json::Allocator<T> alias was leaving most of the allocation un-wiped.

2. jsontestrunner declares a std::string where the surrounding code uses Json::String. Identical types in default builds, different under secure memory, so the runner does not compile. One line.

3. CZString's move-assignment releases a key with releasePrefixedStringValue, but CZString keys come from duplicateStringValue and carry no length prefix. The destructor already uses the matching releaseStringValue. Under the default allocator the mismatch is survivable; under SecureAllocator the suite segfaults. This is the one that only appears after the first two are fixed.

Verification. Before: error C3861. With only 1 and 2 fixed: builds, then jsoncpp_test (SEGFAULT). With all three: secure build compiles and 3/3 ctest suites pass. The default build is unaffected and also 3/3.

Fixes #1399, which reported both the portability problem and that "the unit tests won't build".

[baylesj]

@greptileai

[greptile-apps]

Greptile Summary

This PR repairs the secure-memory configuration by making memory wiping portable and complete, matching CZString deallocation to its allocation format, and using allocator-compatible string types in the test executables.

• Removes the undeclared Windows-specific secure-zeroing call and wipes the complete allocation through a volatile byte view.
• Releases moved CZString keys with the non-prefixed deallocator used by their allocation path.
• Converts affected test and runner strings and streams to JsonCpp’s allocator-aware aliases.
• Adds focused CZString move-operation coverage.

Confidence Score: 5/5

The PR appears safe to merge, with no actionable correctness or security failures identified in the changed paths.

The allocator now wipes the full allocated byte range using supported portable operations, CZString cleanup matches its allocation format, and the affected secure-build test interfaces consistently use allocator-aware string types.

Important Files Changed

Filename	Overview
include/json/allocator.h	Replaces the undeclared Windows-only zeroing call with the portable volatile fill path and corrects the wipe length for arbitrary allocator element sizes.
src/jsontestrunner/main.cpp	Uses Json::String for filename extraction so the runner remains allocator-compatible in secure-memory builds.
src/lib_json/json_value.cpp	Corrects CZString move-assignment cleanup to use the deallocator matching its non-prefixed key allocation.
src/test_lib_json/main.cpp	Converts affected test data, streams, helpers, and containers to allocator-aware JsonCpp string aliases and adds CZString move coverage.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Secure-memory build enabled] --> B[Json::String uses SecureAllocator]
  B --> C[Allocator deallocation]
  C --> D[Volatile wipe of n times sizeof T bytes]
  D --> E[Global delete]
  B --> F[CZString owning key]
  F --> G[Move assignment releases prior key]
  G --> H[releaseStringValue with stored length]
  H --> I[Take source key ownership]

Loading

_{Reviews (1): Last reviewed commit: "Merge branch 'master' into fix-secure-me..." | Re-trigger Greptile}

[coveralls]

Coverage Report for CI Build 32423582949

Coverage remained the same at 89.907%

Details

• Coverage remained the same as the base build.
• Patch coverage: No coverable lines changed in this PR.
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	2740
Covered Lines:	2615
Line Coverage:	95.44%
Relevant Branches:	2640
Covered Branches:	2222
Branch Coverage:	84.17%
Branches in Coverage %:	Yes
Coverage Strength:	23828.01 hits per line

---

💛 - Coveralls

[baylesj]

We probably want to add a GitHub Action for this build configure to ensure that it does not regress. Added an issue:

#1712