Re: [hatari-devel] fixing errors reported by GCC 10 -fanalyzer

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 11/05/2020 à 17:05, Eero Tamminen a écrit :

> "Impossible things" shouldn't happen in Hatari's final releases if 
> they've been properly tested,
> so I think it's OK to disable asserts for them
> (although I would prefer them being enabled
> there also).

Hi

I agree that in a perfect world that would be the case, but bugs reports 
over the year unfortunately show that users don't use devel/alpha/beta 
version of hatari and that we don't have enough man power to go through 
lots of games/demos testing before each release to ensure we don't have 
regression or bugs or crashes.

Most of the time, we get valuables/reproducable bug reports once the 
version is released (without assert() ). Not every bug in that case lead 
to a crash, but I'm afraid the user base of devel version is not large 
enough to ensure "impossible things" have all been tested and won't 
happen on the final release.

My point is more : each time there's a assert(), shouldn't we try to 
remove it by studying all entry points of the code with that assert and 
ensure the cause is cured at the root ?

For example, in floppy.c there're some assert to ensure drive is not >= 
max_floppy_drive. Of course we shouldn't let that happen, but then we 
should find all possible places where "drive" can be changed and fix 
them once for all if needed.
I mean why "drive" is tested with an assert and not "nHBL" or 
"cycles_per_line" or any variable that can index an array ? C is a 
language that allows directly accessing memory, it has its advantage but 
can also lead to memory corruption. To avoid this, we should have 
quality code (which I think we have often).

I don't think assert() are a long time solution of "impossible things 
that shouldn't happen but happen anyway". If they happen, then there's a 
bug that can maybe be fixed by doing more in depth study of the code's 
logic (as gcc 10 -fanalyzer is trying to do, with many false positive at 
the moment).


Nicolas