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

[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

[gammatester]

Zitat von 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.

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
function Base64DecStr({$IFDEF CONST}const {$ENDIF} es: BString): BString;

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

[gammatester]

Zitat von a.def:

Wenn man folgendes auskommentiert

Delphi-Quellcode:

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

Weil der Funktionsrückgabewert ist ja eh schon BString
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 von 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.

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.