Workaround for false positive -Wmaybe-uninitialized being triggered on some compilers
Some toolchains (in this case referring to a g++ 4.9, or "arm-linux-
androideabi-g++ (GCC) 4.9 20140827 (prerelease)" according to my
--version, from the Android NDK r10e-rc4 and potentially with custom
patches; others may be affected as well) fail to prove that myVec in
WebRtcIsac_CorrelateInterVec is never used uninitialized. This is likely
due to the compiler thinking the assignment in line 468 might not
happen. Changing the loop condition in line 466 to rowCntr <
SOME_CONSTANT also helps, suggesting that the compiler can't infer that
there are only 2 values interVecDim can have at that point, and neither
of them are 0. Of course, this is not an acceptable fix, as it changes
behaviour.
This seems to be a compiler bug, or at least an issue with its
heuristics. However, we can't really change toolchains at the moment,
and ultimately this change improves support for certain older compilers.
BUG=
Review URL: https://codereview.webrtc.org/1406423004
Cr-Commit-Position: refs/heads/master@{#10337}
diff --git a/webrtc/modules/audio_coding/codecs/isac/main/source/encode_lpc_swb.c b/webrtc/modules/audio_coding/codecs/isac/main/source/encode_lpc_swb.c
index d59f748..12a263d 100644
--- a/webrtc/modules/audio_coding/codecs/isac/main/source/encode_lpc_swb.c
+++ b/webrtc/modules/audio_coding/codecs/isac/main/source/encode_lpc_swb.c
@@ -440,7 +440,7 @@
int16_t rowCntr;
int16_t colCntr;
int16_t interVecDim;
- double myVec[UB16_LPC_VEC_PER_FRAME];
+ double myVec[UB16_LPC_VEC_PER_FRAME] = {0.0};
const double* interVecDecorrMat;
switch(bandwidth)
