Re: [hatari-devel] undefined behaviour fixes

[Thomas Huth <th.huth@xxxxxxxxx>]

On 07/01/2025 18.23, Andreas Grabher wrote:
....
> I saw this commit and I am not sure if it should be done this way: https:// 
> git.tuxfamily.org/hatari/hatari.git/commit/? 
> id=108c56a1cb71e78326f142f0d892a6cadf5460dc <https://git.tuxfamily.org/ 
> hatari/hatari.git/commit/?id=108c56a1cb71e78326f142f0d892a6cadf5460dc>
>
> I think -fwrapv should always be set, because it produces different (safe 
> from undefined behaviour) code. See here for an example: https:// 
> stackoverflow.com/questions/47232954/what-does-fwrapv-do <https:// 
> stackoverflow.com/questions/47232954/what-does-fwrapv-do>
>
> 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.
>
> Furthermore I think the CPU code should be cleaned from those cases on the 
> long term. So probably do not set -fwrapv if the sanitiser is activated to 
> keep the affected code visible.

FWIW, I just spotted by accident that the new C23 standard will enforce 
two's complement for negative values:

 https://en.wikipedia.org/wiki/C23_(C_standard_revision)#Obsolete_features

.... so I hope that undefined behavior with shifting negative values should 
be gone with future versions of the C compilers.

 Thomas