Integerüberlauf bei Hash-Funktion

[cltom]

Danke für Deine Rückmeldung!

Zitat von himitsu:

In "neuen" Delphi-Projekten sind, seit einer Weile im Delphi, standardmäßig die Index- und die Bereichsprüfung aktiv.
Bei sowas direkt in der betreffenden Unit dieses deaktivieren, wenn dort "absichtlich" mit Überläufen gerechnet wird, wie z.B. bei Verschlüsselung und Hash.
{$OVERFLOWCHECKS OFF}

Das Schlimme ist auch, dass es in der Hilfe "falsch" drin steht.
https://docwiki.embarcadero.com/RADS...ecking_(Delphi)

OK, für den Compiler ist es per Default off, aber in den neuen DPROJ nun per Default on.

Erklärt das, warum ich bei den Projektoptionen des alten (funktionierenden) Projekts die Überlaufsprüfung aktivieren kann und es trotzdem klappt als auch beim neuen Projekt die Überlaufsprüfung deaktivieren kann und es trotzdem nicht geht? bedeutet das auch, dass ich die nötigen Einstellungen gar nicht in den Projekteinstellungen selber ändern kann?

Zitat von himitsu:

Muß es unbedingt dieser Hash sein?
Im Delphi werden standardmäßig ein paar Hash-Funktionen mitgeliefert. (nutzt Delphi z.B. im TDictionary)

Das ist wohl sicher die Antwort, diesen Teil rauszunehmen. Im Kern wird das letztlich wie ein Dictionary verwendet. Als der Code geschrieben wurde, gab es keine Generics und ich hab den Teil bis dato nicht angerührt. Aber ja, das wird mal fällig. Vielleicht ist das Thema der Weckruf, das mal anzugehen. Schön wäre es, wenn es nicht ganz so erzwungen kommt und ich das mal testen kann.

[himitsu]

Direkt in der Unit (vor diesem Code oder irgendwo am Anfang) müsste es sich deakivieren lassen.

Zitat:

Erklärt das, warum ich bei den Projektoptionen des alten

"wo" aktivieren?

Es gibt ja mehrere Configs/Platforms und es muß in der Aktiven gesetzt/abgeschaltet sein. (oder in Einer irgendwo drüber, wenn es in der Linie nirgendwo ab dort überschrieben wurde)

[hoika]

Hallo,
ein paar Gedanken dazu.

s[i]
Du nimmst immer den gleichen "Problemstring" bei den gleichen Projekten?

Wann genau (bei welchem i) kommt der Überlauf,
welcher Buchstabe steht dort?

Bei den Projektoptionen fällt mir noch das Alignment ein,
was aber hier nicht der Grund sein sollte, aber naja ...

Die Projekte benutzen die gleiche Delphi-Version?

[cltom]

Zitat von hoika:

Hallo,
ein paar Gedanken dazu.

s[i]
Du nimmst immer den gleichen "Problemstring" bei den gleichen Projekten?

Wann genau (bei welchem i) kommt der Überlauf,
welcher Buchstabe steht dort?

Bei den Projektoptionen fällt mir noch das Alignment ein,
was aber hier nicht der Grund sein sollte, aber naja ...

Die Projekte benutzen die gleiche Delphi-Version?

Danke für die Überlegungen! Ja, hab gerade auf 12.1 aktualisiert. Die alten Projekt-Dateien funktionieren (offenbar mit anderen Einstellungen), ein neues Projekt mit genau der Funktion ergibt den Fehler.

Was meinst Du mit Alignment?

Ja, es ist immer der gleiche Problemstring, ich hab durch Probieren noch andere gefunden, es scheint aber zahlreiche/unbegrenzt Problemstrings zu geben: ich hab hier immer mehr vom Original-String durch x ersetzt, die werfen allesamt einen Fehler:

lbl_xxxxxx_xxxxxxxxxxxxxxx_xxx

je mehr x, desto früher in der Schleife kommt der Fehler. Der "Original-Problemstring" erzeugt erst an Stelle 30 den Fehler.

Dh im Grunde reicht schon

xxx_xxxxxx_x

Völlig eigen, dass das 15 Jahre lang nur aufgrund der Compiler-Projekt-Einstellungen unbemerkt geblieben ist

[himitsu]

Wie gesagt, in neueren Delphis sind in neuen Projekten diese Optionen jetzt aktiv.
Genauer ist es in der Basis-"Debug"-Config gesetzt.
Nach "check" in der DPROJ suchen.

Es macht auch einen Unterschied, ob das Projekt neu erstellt wird, oder ob die DPROJ gelöscht und anhand der DPR neu generiert wird.
Also allgemein, aber hierbei nicht, wenn in selber DelphiVersion, aber natürlich wenn uralte DPROJ gelöscht und in neuem Delphi neu generiert.

[Stevie]

Viele Algorithmen und gerade Hashfunktionen basieren darauf, dass ein Überlauf keinen Fehler erzeugt.
In der Zeile hier wird ja auf den laufenden Wert von h immer der Ordinalwert des aktuellen Zeichens addiert und das wird kann nunmal irgendwann in einer bestimmten Konstellation zu einem Overflow führen.

Ohne diese für diesen Code explizit abzuschalten, war das schon immer eine tickende Zeitbombe.

[cltom]

Zitat von Stevie:

Viele Algorithmen und gerade Hashfunktionen basieren darauf, dass ein Überlauf keinen Fehler erzeugt.
In der Zeile hier wird ja auf den laufenden Wert von h immer der Ordinalwert des aktuellen Zeichens addiert und das wird kann nunmal irgendwann in einer bestimmten Konstellation zu einem Overflow führen.

Ohne diese für diesen Code explizit abzuschalten, war das schon immer eine tickende Zeitbombe.

das ist wohl eine sehr treffende und letztlich entscheidende Zusammenfassung. Ganz glücklich war ich mit dem Ding nie, jetzt muss ich es wohl "schneller" (nach 15 Jahren) als geplant umbauen.