BUG: Do fslio's size and offset arithmetic at 64-bit width

[gdevenyi]

fslio computes buffer sizes and file offsets from short dimensions and int word sizes, so the products are evaluated in int and truncated before they are assigned to the size_t that holds them.

volbytes = xdim * ydim * zdim * wordsize;   /* all int; wraps past 2GB */
offset   = ((ydim * zVox + yVox) * xdim + xVox) * wordsize;

FslGetVolSize() has the same shape. Each operand is now widened before the multiply, so the arithmetic happens at the width of the result.

Split out of #52, which is otherwise mechanical cast work to silence -Wshorten-64-to-32. This is the one real defect in that set, so it is worth reviewing on its own. #52 no longer contains it.

Note fsliolib/ is behind USE_FSL_CODE, which defaults to OFF, so the standard workflows do not compile it. Verified locally with -DUSE_FSL_CODE=ON; the test suite is unchanged.

🤖 Generated with Claude Code

[hjmjohnson]

Rebased onto master b4876bf, commit message cleaned, and a red-green regression test added. 28 ancestor commits are already upstream under new SHAs and dropped out; the branch is now the one fix commit plus a test.

Message cleanup

Removed the Co-Authored-By: naming an AI tool and the Claude-Session: URL. Replaced the bare #22 cross-reference with words (this is a fork, so the number names a different PR upstream).

Corrected one stale claim: the body said the same defect was "already fixed in FslSeekVolume() in the previous commit". That commit is not in this branch and FslSeekVolume() is unfixed on master — see the follow-up note below. The body now also states the undefined-behavior nature of the overflow, which is what the test showed.

Test and red proof

Added fsliolib/fslio_volsize_test.c, registered as ctest fslio_volsize_64bit. It drives FslGetVolSize() with dimensions whose product exceeds INT_MAX and asserts the exact 64-bit value, plus a 64x64x32 case so an over-broad change cannot pass it.

With the FslGetVolSize() hunk reverted, in a -DCMAKE_BUILD_TYPE=Debug build:

363: FAILURE: 2048x2048x1024: got 0, expected 4294967296
363: FAILURE: 3000x3000x300: got 18446744072114584320, expected 2700000000
1/1 Test #363: fslio_volsize_64bit ..............***Failed    0.21 sec

With the fix restored it passes.

Worth recording: in a Release build the reverted code passes too. The int product is signed overflow, so it is undefined, and clang at -O2 on arm64 folds it to the correct 64-bit result; at -O0 it yields 0. That is the argument for the fix rather than against it — the current code's correctness depends on the optimization level — but it means the red proof only reproduces in an unoptimized build, and the registered test would not have caught this on a Release-only dashboard.

Build and test

Configured with -DNIFTI_BUILD_APPLICATIONS=ON -DUSE_NIFTI2_CODE=ON -DUSE_CIFTI_CODE=ON -DUSE_FSL_CODE=ON, Release and Debug. 363/363 tests pass in both. No whitespace churn: git diff -w master HEAD and git diff master HEAD show the same 51 added lines.

Follow-up for the maintainer, not fixed here. FslSeekVolume() immediately above FslGetVolSize() still truncates:

int offset;
offset = fslio->niftiptr->iname_offset +
  vols * FslGetVolSize(fslio) * fslio->niftiptr->nbyper;

Now that FslGetVolSize() returns a correct size_t, the product is formed at 64 bits and then assigned to an int, so seeking past 2GB is still wrong — the truncation just moved one line down. Fixing it means changing offset to long long and matching znzseek()'s offset type. I left it out to keep this PR to its stated scope; say the word and it can be folded in.