We should calculate an upper bound of these and check if that's valid.

i < iSndCrdFrameSizeFactor which is a small number (usually 1, 2 or 4).
iNumAudioChannels is 1 or 2.
SYSTEM_FRAME_SIZE_SAMPLES is 64 and iOPUSFrameSizeSamples is either that or twice that.

So the result should be < 16K.

Exactly, which illustrates why the CodeQL warning is silly in a lot of contexts, including this one.

I have mentioned an alternative way to fix it in the comments on #3161, and have what I think is an even better way just compiling and about to push to a branch.

We're more likely to see buffer overruns -- but we don't.

vecZeros and vecsStereoSndCrd are 2 * Sound.Init ( iPrefMonoFrameSize ), so likely to be < 16K as well.

I think iSndCrdFrameSizeFactor is used to ensure the buffer overruns don't happen, in fact - calculated from the Sound.Init result.

The CodeQL warnings we are addressing are nothing to do with buffer overruns. Just a perceived arithmetic overflow that will never happen with the values we are using.

With i, iNumAudioChannels and iOPUSFrameSizeSamples as int, however, MAX_INT * MAX_INT * MAX_INT would be out of bounds for the index type.

I don't think this fixes it. The multiplication is still done at the smaller size, before casting the result to the larger size, which is already implicit in the [] operator.

To do it by casting, I think you only cast i, which makes the multiplication be done all at size_t:

...[(static_cast<size_t>(i)) * iNumAudioChannels * iOPUSFrameSizeSamples]
...

Multiplication will be done in the type of the first operant. Nevertheless if the result is assigned to a smaller type there should still be a check to handle any overflows.