|Re: [hatari-devel] fixing errors reported by GCC 10 -fanalyzer
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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
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