Re: [hatari-devel] undefined behaviour fixes

[David Savinkoff <dsavnkff@xxxxxxxxx>]

Hi,
This filter's function call is passed an int16_t and returns an int16_t.
The filter calculates using int32_t so that there is no possibility of
shifting too much. This is why there is no warning.
I love the 1 clock cycle barrel shifter in non-legacy CPUs.

On Fri, Jan 10, 2025 at 11:37 PM Thomas Huth <th.huth@xxxxxxxxx> wrote:
>
> Am Sat, 11 Jan 2025 07:30:35 +0000
> schrieb Thomas Huth <th.huth@xxxxxxxxx>:
> ...
> >
> > > Because I still think it is bad coding style to shift negative values and similar in my opinion we should only set -fwrapv where really necessary. So we should probably only do that in the CPU core, like in my previous patch. As I said previously, the parts of Hatari that are used in Previous including the DSP do not trigger any warning. So Hatari is aside from the CPU core likely to be clean and should stay like that.
> >
> > It's not. There is at least one more spot in the sound code:
> >
> >  src/sound.c:389:18: runtime error: left shift of negative value -893
> >
> > Maybe Nicolas could have a look at it? ... those filters
> > are not really my turf.
>
> I guess the fix would be as easy as:
>
> diff --git a/src/sound.c b/src/sound.c
> --- a/src/sound.c
> +++ b/src/sound.c
> @@ -386,8 +386,8 @@ ymsample    Subsonic_IIR_HPF_Left(ymsample x0)
>         if ( YM2149_HPF_Filter == YM2149_HPF_FILTER_NONE )
>                 return x0;
>
> -       y1 += ((x0 - x1)<<15) - (y0<<6);  /*  64*y0  */
> -       y0 = y1>>15;
> +       y1 += ((x0 - x1) * 32768) - (y0 * 64);  /*  64*y0  */
> +       y0 = y1 / 32768;
>         x1 = x0;
>
>         return y0;
>
> ?
>
>  Thomas
>
>