Re: [hatari-devel] undefined behaviour fixes

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


One thing that one must know is that all twos complement CPUs work the same
(intel 8008, motorola 6800, 6502, and all motorola and intel afterwards).
It is foolish to challenge two's complement when it is used on CPU's where
Computer Scientists with Electronics Engineering degrees, not headstrong
wannabe quality control and programmers are the Real designers.
Modern compiler writers are heading in the wrong direction.

On Thu, Jan 23, 2025 at 7:38 AM Andreas Grabher <andreas_g86@xxxxxxxxxxx> wrote:
>
>
> > Am 23.01.2025 um 08:14 schrieb 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
> >
> That does not necessarily mean that shifting negative values is going to be defined in the future, but i hope so.
>
> Even with two‘s complement shifting 0b10000000 >> 1 might result in 0b01000000 or 0b11000000. Let‘s hope they also define how to handle the sign bit.
>



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/