search for: silk_add32_ovflw

Hi Jean-Marc, well spotted! The patch provided fixes the issue for me. Nevertheless, in my code (and I would suggest doing the same in libopus) I am going to replace the function with one that accumulates on 64 bits and then calculates the shift, for at least 4 reasons: - It is less and simpler code - The result is likely to be slightly more accurate in case big numbers come early in the

Hi Marcello, Actually, we were careful to avoid the undefined behaviour here. In fact, we are specifically running a clang test detecting undefined behaviour. If you look at the silk_SMLABB_ovflw() macro, you will see it is based on silk_ADD32_ovflw(), which is defined as: #define silk_ADD32_ovflw(a, b) ((opus_int32)((opus_uint32)(a) + (opus_uint32)(b))) By casting to unsigned, all the cases are well defined. The cast back to int is implementation-defined but we are already assuming two's complement behaviour every time we are shifting....

...lt;jmvalin at jmvalin.ca> wrote: > Hi Marcello, > > Actually, we were careful to avoid the undefined behaviour here. In > fact, we are specifically running a clang test detecting undefined > behaviour. If you look at the silk_SMLABB_ovflw() macro, you will see it > is based on silk_ADD32_ovflw(), which is defined as: > > #define silk_ADD32_ovflw(a, b) ((opus_int32)((opus_uint32)(a) + > (opus_uint32)(b))) > > By casting to unsigned, all the cases are well defined. The cast back to > int is implementation-defined but we are already assuming two's > complement behav...