More clang-tidy fixes

[seanm]

No description provided.

[seanm]

@hjmjohnson these changes are quite conservative, care to review?

@gdevenyi maybe you'd like to review too?

[gdevenyi]

@seanm you asked me to review this back in July — sorry for the delay.

LGTM. I checked each hunk: the NT_DT_* and nvals changes are pure parenthesisation with identical expansions at every existing call site, the (size_t) casts in FslReadSliceSeries/FslReadTimeSeries widen before the multiply rather than after, and -4L*count fixes the same class in znzseek. Both headers you touch (nifti_tool.h, nifti1_tool.h) are not installed, so none of it is an interface change.

[hjmjohnson]

Rebased onto current master (b4876bf) and both commit messages reworded. The diff is unchanged.

One thing worth a maintainer's eye before merge: the d3matrix() hunk does not fix the widening it looks like it fixes — see below.

Rebase

master's last 44 commits were rewritten on 2026-09-22 (messages only, trees byte-identical), so this branch's base no longer existed and GitHub reported it CONFLICTING. Rebased with git rebase --onto master 61f5042^; both commits applied without conflict. diff <(git diff master HEAD) <(git diff 61f5042^ 332003a) differs only in blob hashes and one hunk line offset, i.e. the content delta is identical.

Commit messages

Both subjects were bare sentences; they now carry the project's STYLE: prefix and are wrapped to 78/72. Author, author date and trees are preserved. Nothing else was stripped — neither commit carried a tool trailer or a transient URL.

No regression test — and why

COSMETIC/latent-hardening throughout; there is no observable behavior to pin red:

• The bugprone-macro-parentheses hunks (NT_DT_*, nvals, rval, the two nifti_tester001.c macro arguments, sz-1) are all invoked today with literals or simple identifiers, so parenthesizing changes no expansion currently in the tree. It guards future call sites.
• -4*count to -4L*count in nifti_read_next_extension(): count is the znzread return and is 0, 1 or 2 on this path, so the product cannot overflow int. Also note long is 32-bit on LLP64 (Windows), so -4L does not actually widen there; (int64_t)-4 would.
• FslReadSliceSeries / FslReadTimeSeries: genuine widening, but reaching it needs a volume whose byte count exceeds INT_MAX, which no fixture in the suite approaches. Note that FslReadTimeSeries's offset = ((ydim * zVox + yVox) * xdim + xVox) * wordsize; on the next line is still computed in int — the fix is partial.
• d3matrix(): this hunk is a no-op, not a fix. The original was malloc((size_t)((nslice*nrow*ncol)*sizeof(double))) — sizeof is already size_t, so the product was already evaluated in size_t and the outer cast was redundant. Removing the redundant cast leaves the arithmetic exactly as it was. If the intent was to fix the widening here, the change needed is casting the int operands ((size_t)nslice * nrow * ncol * sizeof(double)), the way the fslio.c byte-count hunks above do it.

Build and test

macOS/arm64, Ninja, Release, -DNIFTI_BUILD_APPLICATIONS=ON -DUSE_NIFTI2_CODE=ON -DUSE_CIFTI_CODE=ON -DUSE_FSL_CODE=ON: builds clean, 100% tests passed, 0 tests failed out of 362.

[seanm]

@hjmjohnson this isn't ITK and doesn't need the STYLE and similar prefixes. But even if it did, neither of these commits are stylistic changes, they are bug fixes. The multiplication widening solves integer overflow, which is a bug, not stylistic.

[seanm]

I have fixed the commit messages.