Hi Thomas,
danke für den sehr gründlichen Bugreport. Ich habe es gerade mit der
DEC 5.2 und D2009 nachvollziehen können. Bei MD5 als Hash tritt der Bug übrigens nicht auf!
Ich versuche jetzt mal zu sehen, welche Hash-Funktionen betroffen sind und woran es liegt.
Edit: Jetzt hab ich mal alle Hashfunktionen durchprobiert.
Ergebnis:
Zitat:
MD2: a/v im C++
MD4: ok
MD5: ok
RipeMD128: ok
RipeMD160: ok
RipeMD256: ok
RipeMD320: ok
SHA: ok
SHA1: ok
SHA256: ok
SHA384: fehlerhaft (C++)
SHA512: fehlerhaft (C++)
Haval128: EIntOverflow (C++)
Haval160: ok
Haval192: ok
Haval224: ok
Haval256: ok
Tiger: Unterschiedlich (aber pro Prozess gleicher Wert in C++)
Panama: ok
Whirlpool: ok
Whirlpool1: ok
Square: Unterschiedlich (aber pro Prozess gleicher Wert in C++)
Snefru128: Unterschiedlich (aber pro Prozess gleicher Wert in C++)
Snefru256: Unterschiedlich (aber pro Prozess gleicher Wert in C++)
Sapphire: ok
Fehlerquote also 7 aus 25.
Da scheinen also einige Hashfunktionen in C++ Probleme zu machen, an den Format-Conversions liegt es jedoch definitiv nicht.
Anmerkung an alle anderen Leser: Dies betrifft nur die Nutzung der
DEC mit Borland C++ Builder.
Nachtrag 2:
Wenn ich den
asm Code für die fehlerhaften Hashfunktionen auskommentiere, z.B. {.$DEFINE THash_SHA384_asm}, funktioniert der native Delphi Code.
Gruß Assertor