[jdotc1]

Reject transform parameter counts that exceed the metric return type. Addresses the diagnostic-guard alternative in #6949.

Scope and risk

This rejects unsupported large counts; it does not add a 64-bit metric API or fix every allocation path. The test uses a dummy count and must not allocate a multi-billion-voxel field.

Validation

6 isolated method-body boundary cases compile and pass under GCC with AddressSanitizer/UndefinedBehaviorSanitizer.

Native ITK validation is now available for current head 5cecfc06745aa8c5e6153e3215b1b5323a52d2ee. The Linux ARM64 job compiled with zero compiler errors and warnings and passed all 4,722 configured tests. The actual CountMetric/CountTransform GTest fixture compiled, and both ObjectToObjectMetric.PreservesRepresentableParameterCounts and ObjectToObjectMetric.RejectsParameterCountOverflow passed.

The current-head platform matrix has completed: 18 checks passed, with no pending or failing reported checks. The only skipped job is publish-doxygen-tagfile. Completed checks include Windows C++, macOS and Ubuntu Pixi C++, x86_64 Rosetta, ARM Python, Azure Linux and macOS Python, pre-commit, Doxygen, performance and documentation. The native Linux ARM64 test results above are reused; no tests were repeated for this status update.

Ready for maintainer review. The results establish the native tests on the completed configurations; they do not establish every possible platform-dependent integer-width combination. Maintainer review is needed before merging.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge.

Summary

Adds a check in GetNumberOfParameters() that throws before a transform count can overflow the metric’s return type.

• Metrics reject transform parameter counts they cannot represent.

No actionable issues found. This review checked the code and test setup; it did not run the tests.

_{Reviews (1) · Last reviewed commit: "COMP: Complete parameter-count metric te..." · Reviewed by Greptile}