Wolfgang Ehrhardts CRC/Hash Routinen - kompilieren schlägt fehl - IDE-Bug?

[a.def]

Ich bin heute auf Wolfgang Ehrhardts CRC- und Hash-Routinen gestoßen. Die sollen wohl wahnsinnig schnell sein, weswegen ich mich dafür interessiere.

Ich habe aber ein seltsames Problem, wenn ich mir die Units die ich brauche ins Projekt hinzufüge und kompilieren möchte.
Der Compiler meckert, dass der Bezeichner THashContext nicht deklariert sei. Wenn ich aber STRG+Linkklick drauf mache, lande ich in der Unit Hash.pas.

Wieso findet der Compiler die Unit nicht?

Ein Beispielprojekt mit allen benötigten Units befindet sich im Anhang. Bekommt ihr das Projekt kompiliert?

Link zu Wolfgang Ehrhardts Units: http://www.wolfgang-ehrhardt.de/crchash_de.html

[gammatester]

Zitat:

Zitat von a.def (Beitrag 1370427)

Ich bin heute auf Wolfgang Ehrhardts CRC- und Hash-Routinen gestoßen. Die sollen wohl wahnsinnig schnell sein, weswegen ich mich dafür interessiere.

Wieso findet der Compiler die Unit nicht?

Ein Beispielprojekt mit allen benötigten Units befindet sich im Anhang. Bekommt ihr das Projekt kompiliert?

Link zu Wolfgang Ehrhardts Units: http://www.wolfgang-ehrhardt.de/crchash_de.html

Das Problem liegt darin, daß Delphi ab XE8 eine eigene Hash-Unit hat, und durch nichts zu überzeugen ist, daß es die Unit im Arbeitsverzeichnis oder entsprechend der Uses-Liste verwendet soll. Ist bekannt, siehe hier http://www.delphipraxis.net/190245-u...nd-hash-2.html und http://www.delphipraxis.net/184810-x...stem-hash.html. Aber selbst dann kann man deinen Code nicht übersetzen (zB mit D18) weil er einige Fehler hat. Eine korrigierte Funktion sieht so aus

Delphi-Quellcode:

function SHA1Text(const s: string): string;
var
 Context: THashContext;
 SHA256Digest: Hash.TSHA256Digest;
begin
 SHA256.SHA256Init(Context);
 SHA256.SHA256Update(Context, pChar(s), length(s));
 SHA256.SHA256Final(Context, SHA256Digest);
 Result := Mem_Util.HexStr(@SHA256Digest, SizeOf(SHA256Digest));
end;

und sollte dann sinnvollerweise SHA256Text heißen. Ich kann selbst dann nicht übersetzen, weil die res-Datei fehlt.

Gruß Gammatester

[a.def]

Heißt das also die einzige Lösung besteht darin, dass ich die Unit Hash von Wolfgang E. umbenennen muss?

Zitat:

Aber selbst dann kann man deinen Code nicht übersetzen (zB mit D18) weil er einige Fehler hat. Eine korrigierte Funktion sieht so aus

Das waren leider noch Code-Leichen. Im neuen Archive oben sind die raus.

Zitat:

Ich kann selbst dann nicht übersetzen, weil die res-Datei fehlt.

Die ist doch gar nicht zwingend erforderlich oder?
Ich kann die aus meinem Projektverzeichnis löschen und nicht kompilieren (siehe Fehler erster Post). Aber auch wenn sie vorhanden ist kann ich nicht kompilieren.

[idefix2]

Zitat:

Zitat von a.def (Beitrag 1370438)

Ich kann die aus meinem Projektverzeichnis löschen und nicht kompilieren (siehe Fehler erster Post). Aber auch wenn sie vorhanden ist kann ich nicht kompilieren.

Naja, zum Nicht-kompilieren ist sie sicher nicht erforderlich :)

[a.def]

Wenn ich hash.pas in W.E.Hash.pas umbenenne, komme ich bereits weiter.
Wo man dann aber stecken bleibt ist in Mem_Util.Base64DecStr in Block

Delphi-Quellcode:

function Base64DecStr({$IFDEF CONST}const {$ENDIF} es: BString): BString;
var
 {$IFNDEF RESULT}
 result: BString;
 {$ENDIF}
...

// Funktioniert mit XE2 problemlos. Ab XE8 nicht mehr.

Wenn man das auskommentiert (ebenfalls in anderen Funktionen wo es diese Re-Deklaration gibt) kommt man weiter und es kompiliert.
Result: BString ist hier meiner laienhaftung Meinung doch gar nicht notwendig, da der Funktionsrückgabewert doch eh schon BString ist.


Resultat dieses kleinen Ausritts ist dann ein SHA256-Hash, der nicht mit dem übereinstimmt was andere Hasher sagen.
Es gibt vermutlich also noch weitere Probleme nur fraglich wo.

Wenn ich diese Library zum problemlosen Funktionieren bekomme, wird es definitiv meine erste Wahl vor allen anderen :thumb:

[gammatester]

Zitat:

Zitat von a.def (Beitrag 1370440)

Wenn ich hash.pas in W.E.Hash.pas umbenenne, komme ich bereits weiter.
Wo man dann aber stecken bleibt ist in Mem_Util.Base64DecStr in Block

Delphi-Quellcode:

function Base64DecStr({$IFDEF CONST}const {$ENDIF} es: BString): BString;
var
 {$IFNDEF RESULT}
 result: BString;
 {$ENDIF}
...

// Funktioniert mit XE2 problemlos. Ab XE8 nicht mehr.

Wenn man das auskommentiert (ebenfalls in anderen Funktionen wo es diese Re-Deklaration gibt) kommt man weiter und es kompiliert.
Result: BString ist hier meiner laienhaftung Meinung doch gar nicht notwendig, da der Funktionsrückgabewert doch eh schon BString ist.

Wenn man was auskommentiert? Und welche Re-Deklaration? BString ist ein String[255], also kein String (bei die wohl bei dir ein Unicode-String ist). Außerdem ist er statisch und nicht dynamisch (Strings in XE8 sind dynamisch).

Wenn du dynamische Strings brauchst, sieh mal in Unit base2n.pas für ansistrings.

[a.def]

Wenn man folgendes auskommentiert

Delphi-Quellcode:

 {$IFNDEF RESULT}
 result: BString;
 {$ENDIF}

Weil der Funktionsrückgabewert ist ja eh schon BString

Delphi-Quellcode:

function Base64DecStr({$IFDEF CONST}const {$ENDIF} es: BString): BString;

Nur dann funktioniert es. Aktuell versuche ich mit Tokyo Starter zu kompilieren.

[gammatester]

Zitat:

Zitat von a.def (Beitrag 1370443)

Wenn man folgendes auskommentiert

Delphi-Quellcode:

 {$IFNDEF RESULT}
 result: BString;
 {$ENDIF}

Weil der Funktionsrückgabewert ist ja eh schon BString

Delphi-Quellcode:

function Base64DecStr({$IFDEF CONST}const {$ENDIF} es: BString): BString;

Nur dann funktioniert es. Aktuell versuche ich mit Tokyo Starter zu kompilieren.

Wenn Du das auskommentieren mußt, stimmt noch mehr nicht. Für Delphi sollte RESULT immer definiert sein: std.inc Zeile 494. (Hinweis: es gibt Pascal-Versionen die kein result für's Funktionsergebnis kennen!)

[a.def]

Wie gesagt. Ich teste es mit XE8 Pro und Tokyo Starter und es tritt bei beiden auf.
Tritt nur bei Tokyo auf. Der Hash ist bei XE8 aber trotzdem nicht korrekt.

[gammatester]

Zitat:

Zitat von a.def (Beitrag 1370445)

Wie gesagt. Ich teste es mit XE8 Pro und Tokyo Starter und es tritt bei beiden auf.
Tritt nur bei Tokyo auf. Der Hash ist bei XE8 aber trotzdem nicht korrekt.

Für Tokyo solltest Du die neueste http://www.wolfgang-ehrhardt.de/std.zip verwenden. Deine ist über ein Jahr alt, da gab es Tokyo noch nicht.

PS: Warum hast du eigentlich so viele Änderungen am Code vorgenommen (zB 124 bei sha256)?

[a.def]

Ich weiß nicht genau von welchen Änderungen du sprichst. Bis auf die Code-Formatierung habe ich nichts ausgeführt.
Irgendetwas mache ich trotzdem noch falsch. Selbst mit der neuen std bekomme ich falsche Ergebnisse.

[gammatester]

Ein letzter Versuch: Wenn Deine Funktion immernoch etwa so aussieht

Delphi-Quellcode:

function SHA1Text(const s: string): string;
var
 Context: THashContext;
 SHA256Digest: Hash.TSHA256Digest;
begin
 SHA256.SHA256Init(Context);
 SHA256.SHA256Update(Context, pChar(s), length(s));
 SHA256.SHA256Final(Context, SHA256Digest);
 Result := Mem_Util.HexStr(@SHA256Digest, SizeOf(SHA256Digest));
end;

hast Du wahrscheinlich ein Problem mit Unicodestrings wegen des pChar(s). Da char 16 Bit ist, müßtest Du auf jeden Fall length(s)*sizeof(char) verwenden. Doch ich bezweifele, daß Du überhaupt die vielen 0-Bytes eines Unicodestring haschen willst. Warum verwendest Du immer noch die dämlichen unangemessenen Strings? Gehascht werden sollte über Byte/Bit-Folgen, wie man es Dir in Deinem anderen Thread bereits nahegelegt hat.

Gute Nacht
Gammatester

[a.def]

Zitat:

Warum verwendest Du immer noch die dämlichen unangemessenen Strings? Gehascht werden sollte über Byte/Bit-Folgen, wie man es Dir in Deinem anderen Thread bereits nahegelegt hat.

Weil

a) ich weiß nicht wie (unkomplizierte Lösung)
b) habe ich den Code da oben bei StackOverflow gefunden
und
c) wenn ich den Hash anzeigen möchte, dann geht das halt nur über Strings.


Ist jetzt aber auch egal das Thema hat sich für mich erledigt.

[gammatester]

Zitat:

Zitat von a.def (Beitrag 1370449)

b) habe ich den Code da oben bei StackOverflow gefunden
und
c) wenn ich den Hash anzeigen möchte, dann geht das halt nur über Strings.

Allerletzter Kommentar:

Es geht ja nicht um die Ausgabe sondern die Eingabe. Der Code wäre halbwegs richtig für Delphi < 12, also prä- D2009 (allgemein, wenn string ein ansistring ist). Wenn Du keine abstrusen Zeichen benutzt, versuche also die Deklaration

Delphi-Quellcode:

function SHA1Text(const s: ansistring): ansistring;

[himitsu]

[edit]
Ich seh grade, dass sich dieses Thema eh endgültig "erledigt" hat.

Na gut, alles Wichtige wurde ja gesagt,
also Punkt und Ende.
[/edit]

Delphi-Quellcode:

function SHA1Text(const s: ansistring): ansistring;

wäre in so weit richtig, wenn der Code die selben Ergebnisse liefern soll, wie vor Delphi 2009.
Das Result wäre natürlich egal, da Hexadezimal als ASCII überall gleich aussieht, also wäre IMHO String dafür ganz passend.

So wäre der Code halbwegs kompatibel zu Hashs, die vor D2009 generiert wurden.




Allerdings ist AnsiString als Eingang auch nicht sonderlich optimal, da es bei Nicht-ASCII-Inputs je nach CodePage (Systemstpache) unterschiedliche Ergebnisse liefern kann wird.

Fazit: Entweder man legt fest, dass eine bestimmte CodePage als Eingang vorgeschrieben ist, z.B. Latin1.

Delphi-Quellcode:

type
  Latin1 = type AnsiString(1252);  // ISO 8859-1

function SHA1Text(const S: Latin1): String;

Oder man legt es besser noch auf einen Unicode-Zeichensatz fest, wie z.B. Unicode (UnicodeString, bzw. auch WideString für vor Delphi 2009) oder besser UTF8String.

Delphi-Quellcode:

function SHA1Text(const S: UTF8String): String;

(seit Delphi 2009 kümmert sich Windows automatisch um eine Konvertierung, wenn man da einen String oder AnsiString rein gibt.

Nur so ist gewährleistet, dass Hashs immer und überall gleich sind.
Blos zu Hashs der alten ANSI-Version ist es nicht kompatibel.

[p80286]

Da Du Dir mit strings/Char immer irgendwelche Unwägbarkeiten einhandelst sollte man, zumindest offizell die Finger davon lassen. Sollte der der String als bequeme Datenstruktur genutzt werden, muß man immer im Hinterkopf behalten, daß man sich da Nebeneffekte einhandeln kann (x00 z.B.)

Das ist nichts für Anfänger und Schusselsköppe,
darum meide ich solche Tricks wie der Teufel das Weihwasser.

Gruß
K-H

[gammatester]

Info: Der Bug ist gefixt in Embarcadero® Delphi 10.2 Version 25.0.26309.314, vgl. https://edn.embarcadero.com/print/44747 link auf RSP-15827

Selbst getestet.
Gruß Gammatester