19.01.2021, 09:24
(Dieser Beitrag wurde zuletzt bearbeitet: 19.01.2021, 11:34 von siebenstreich.)
Zum 99 BP-Bug muss ich zurückrudern. Was ich 3 Beiträge weiter oben geschrieben habe, stimmt nicht so recht. Insbesondere wird der vorgeschlagene Bugfix nicht funktionieren, also bitte vergessen!
Die Funktion FIG_backtrack terminiert Pfade, die ihr Ziel erreichen mit einer Endmarke -1. Anders als von mir zuvor behauptet werden Pfade zu einem Ziel, das mit den vorhandenen BP nicht erreicht werden kann, mit dem Doppeleintrag [-1, -2] terminiert. Bei dem Bug wird ja fälschlicherweise "ZIEL: 99 BP" ausgegeben. Die Zahl 99 muss meiner Meinung nach aus der Funktion Funktion FIG_move_pathlen in seg034.cpp stammen, weil ich nicht sehe, wo sie sonst produziert werden könnte. In dieser Funktion wird bei der zweiten Variante der Terminierung (also [-1,-2]) 99 zurückgegeben. Zuerst dachte ich, dass evtl. Reste des vorherigen Pfads im Speicher etwas durcheinanderbringen könnten, wenn zufällig noch ein -2 an der entscheidenden Stelle hinter einer geschriebenen Endmarke -1 steht. Aber ich hatte übersehen, dass die Einträge des Pfads vor der Neuberechnung per memset auf 0 gesetzt werden.
Mir ist schleierhaft, wie es beim Aufruf von FIG_move_pathlen in seg034.cpp zur Ausführung der Zeile GUI_print_string(problem == 1 ? get_tx(13) ...) dazu kommen kann, dass die "ZIEL: BP..."-Meldung ausgegeben wird.
Denn das hängt von der Variable 'problem' ab. Die davor stehende if .. else if .. else if ... Serie zum Setzen von problem ist etwas unübersichtlich, aber ich sehe nicht, wie in den beobachteten Fällen des Bugs problem==0 überleben soll.
Die Funktion FIG_backtrack terminiert Pfade, die ihr Ziel erreichen mit einer Endmarke -1. Anders als von mir zuvor behauptet werden Pfade zu einem Ziel, das mit den vorhandenen BP nicht erreicht werden kann, mit dem Doppeleintrag [-1, -2] terminiert. Bei dem Bug wird ja fälschlicherweise "ZIEL: 99 BP" ausgegeben. Die Zahl 99 muss meiner Meinung nach aus der Funktion Funktion FIG_move_pathlen in seg034.cpp stammen, weil ich nicht sehe, wo sie sonst produziert werden könnte. In dieser Funktion wird bei der zweiten Variante der Terminierung (also [-1,-2]) 99 zurückgegeben. Zuerst dachte ich, dass evtl. Reste des vorherigen Pfads im Speicher etwas durcheinanderbringen könnten, wenn zufällig noch ein -2 an der entscheidenden Stelle hinter einer geschriebenen Endmarke -1 steht. Aber ich hatte übersehen, dass die Einträge des Pfads vor der Neuberechnung per memset auf 0 gesetzt werden.
Mir ist schleierhaft, wie es beim Aufruf von FIG_move_pathlen in seg034.cpp zur Ausführung der Zeile GUI_print_string(problem == 1 ? get_tx(13) ...) dazu kommen kann, dass die "ZIEL: BP..."-Meldung ausgegeben wird.
Denn das hängt von der Variable 'problem' ab. Die davor stehende if .. else if .. else if ... Serie zum Setzen von problem ist etwas unübersichtlich, aber ich sehe nicht, wie in den beobachteten Fällen des Bugs problem==0 überleben soll.