fix(FIR): size q15 state buffer for ARM_MATH_LOOPUNROLL, not just ARM_MATH_DSP

[94xhn]

Fixes #305.

Problem

arm_fir_init_q15() only allocates the larger (numTaps+blockSize) state buffer when ARM_MATH_DSP is defined; otherwise it allocates the smaller (numTaps+blockSize-1), per the function's own documentation.

arm_fir_q15()'s non-MVE processing function has a separate ARM_MATH_LOOPUNROLL-gated code path (processes 4 samples at a time using read_q15x2_ia()/__SMLALD()/__PKHBT()) that reads up to state-buffer index numTaps+blockSize-1 - one element past what's allocated whenever ARM_MATH_LOOPUNROLL is defined without ARM_MATH_DSP. This is a real, reachable configuration: read_q15x2_ia()/__SMLALD()/__PKHBT() all have portable non-hardware-DSP fallback implementations (in Include/arm_math_memory.h / Include/dsp/none.h), so ARM_MATH_LOOPUNROLL doesn't itself require ARM_MATH_DSP to compile or run - it just happens that most real projects define both together.

Verification

I extracted the exact access pattern of arm_fir_q15()'s loop-unrolled scalar path (read_q15x2_ia/__SMLALD/__SMLALDX/__PKHBT, matching the portable fallback definitions) into a standalone host reproduction, and placed the state buffer immediately before a PAGE_NOACCESS guard page (VirtualAlloc) so any read past the documented allocation size faults immediately instead of silently touching adjacent heap memory:

• With the current (numTaps+blockSize-1)-sized buffer (the un-fixed !ARM_MATH_DSP sizing): the reproduction crashes with an access violation (STATUS_ACCESS_VIOLATION, 0xC0000005).
• With a (numTaps+blockSize)-sized buffer (the ARM_MATH_DSP-defined sizing): the reproduction completes cleanly.

This confirms the out-of-bounds read is real and reachable, not just a theoretical pointer-arithmetic concern.

Fix

Changed arm_fir_init_q15()'s sizing condition from #if defined(ARM_MATH_DSP) to #if defined(ARM_MATH_DSP) || defined(ARM_MATH_LOOPUNROLL), so the larger buffer is allocated whenever the loop-unrolled path is actually in use, regardless of whether hardware DSP instructions or their software fallback are what's actually executing it. Updated the docstring to match.

Scope note

I checked the q31/q7/f32 FIR init functions for the same pattern - arm_fir_init_q31.c and arm_fir_init_f32.c have additional, different conditional sizing logic (not a simple ARM_MATH_DSP gate), and arm_fir_init_q7.c doesn't have this ARM_MATH_DSP-gated branch at all - so I did not attempt to extend this same fix to them without separately, individually verifying each one, which is outside the scope of this specific issue.

Disclosure

Generative AI (Claude) was used to help investigate this issue, implement, and verify this fix. All changes were reviewed by me before submission.

[christophe0606]

I have added a few comments to address.