[Allegro] Globale Ersetzung in Indexparametern gestoert?

[Thomas Berger]

Lieber Herr Eversberg,

das folgende scheint index.exe seit mindestens v32.4 zu betreffen,
moeglicherweise ist der Fehler also "schon immer" drin, d.h. seit
es die Quadriga-Programme gibt.

Ueberprueft habe ich es zumindest mit den Versionen vom 14.4.15
(v35.4,5,6), 20.3.15 (v35.3), 7.7.14 (v34.3), 23.5.13 (v33.3)
und 7.5.12 (v32.4).

In einer HANS-hpi-Datei habe ich vor kurzem (als einzige globale
Ersetzung) die folgende Zeile eingebaut:

*#806w_; _^P_

(^P das einzelne Zeichen 16 "►")

Dies fuehrt u.U. dazu, dass in *keinem* Satz mehr Kategorien #541 oder
#700 sichtbar sind. (In einem anderen Aufrufszenario - gleiche
Verzeichnisse, gleiche Parameterdateien, nur etwas anderes Environment
bei Umgebungsvariablen ohne Bezug zu allegro) sind diese da, dafuer
fehlen insgesamt mehr Schluessel, ~15% der Gesamtzahl). Ich konnte
anhand der II-Dateien vor dem qrix-Aufruf verifizieren, dass die
vermissten Schluessel bereits in den von index.exe produzierten,
"kleinen" ii-Dateien fehlen.

Deaktiviere ich diese (einzige) Globalersetzungszeile, sind die
in beiden Szenarien produzierten ii-Dateien gleich (und etwas
umfangreicher als vorher), die vermissten Schluessel sind da, einen
positiven Beweis, dass *alle* Schluessel auch wirklich produziert
werden, habe ich leider nicht. Es gibt also eine kleine Chance,
dass die Daten boese sind und die Ersetzung nur besonders allergisch
darauf reagiert (es gibt ein paar Saetze, die nicht ganz sauber
sind, die sind aber seit Jahren friedlich).

Der Fehler bleibt unveraendert, wenn ich den Ersetzungsbefehl auf

*#806x_; _^P_

aendere, wobei ich ueberprueft habe, dass #806x in der Datenbank
in keinem Datensatz vorkommt: Bereits der (stets erfolglose) Test
auf die Anwendbarkeit der Ersetzung ist also problematisch. Die
eigentliche Ersetzung kann ich variieren, auch

*#806x_xxx_yyy_

ergibt kein anderes Bild.

Leider verstehe ich nicht wirklich, was in acore.c nri cmd_ast
und cmd_y passiert (do you really need to redefine NULL?),
mir scheint an einer Stelle in den Suchbegriff im Phrasenspeicher
eine ASCII 0 hineingeschrieben zu werden, so dass er evtl. ab dem
zweiten Datensatz nicht mehr wirklich brauchbar ist (koennte er
dann ganz unerwartet wirken?)

Mit der Demo-Datenbank zu $A.CFG kann ich das Verhalten leider nicht
reproduzieren, aber vielleicht gibt Ihnen das Fehlerbild eine
Idee, wenn Sie als Kundiger auf den Code gucken?

viele Gruesse
Thomas Berger