DEC 5.2 Fehler unter Delphi 2009 (?)

[ULIK]

Hallo,

ich bin gerade auf das folgende Problem gestoßen: Eine Logik, die unter Delphi 2007 funktioniert liefert unter Delphi 2009 falsche Ergebnisse. Hier der Code der Unit-Tests (DEC5_xyz bezeichnet die Unit xyz aus DEC 5.2)

Delphi-Quellcode:

procedure TTestgoDecUnitHashes.TestHashHEX;
var
  strResultV3: ANSIString;
  strResultV5: ANSIString;
  cResult: Cardinal;
begin
  // FText (:ANSIString) := 'This is a confidential ANSI Text';
  strResultV3 := '03BEBC72'; //Hash.THash_CRC32.CalcString(FText, nil, fmtHEX);

  cResult := DEC5_CRC.CRCCalc(CRC_32CCITT, PAnsiChar(FText)^, Length(FText));
  strResultV5 := DEC5_DECFmt.TFormat_HEX.Encode(cResult, 4);

  CheckEqualsString(strResultV3, strResultV5);
end;

procedure TTestgoDecUnitHashes.TestHashHEX_new;
var
  strResultV3: ANSIString;
  strResultV5: ANSIString;
  cResult: Cardinal;
  objCRCDef: DEC5_CRC.TCRCDef;
  strKey: ANSIString;
  cVector: Cardinal;
begin
  // FText (:ANSIString) := 'This is a confidential ANSI Text';
  strResultV3 := '03BEBC72'; //Hash.THash_CRC32.CalcString(FText, nil, fmtHEX);

  DEC5_CRC.CRCSetup(objCRCDef, $04C11DB7, 32, $FFFFFFFF, $FFFFFFFF, True);
  DEC5_CRC.CRCCode(objCRCDef, PAnsiCHar(FText)^, Length(FText));
  cResult := DEC5_CRC.CRCDone(objCRCDef);

  strResultV5 := DEC5_DECFmt.TFormat_HEX.Encode(cResult, 4);

  CheckEqualsString(strResultV3, strResultV5);
end;

Die beiden obigen Unit-Tests laufen durch, wenn sie unter Delphi 2007 kompiliert werden. Unter Delphi 2009 jedoch schlägt der erste Test fehl. Das Problem dürfte darin liegen, daß der Hash im ersten Fall mit CRCInit initialisiert wird (aufgerufen von CRCCalc), was bei mir unter Delphi 2009 komische Werte liefert. Bug oder Feature?

Grüße,
Uli

[Assertor]

Hi Uli,

bei mir liefert TestHashHEX 03BEBC72 mit DEC 5.2 und D2009.

Übrigens: Glückwunsch zum "Lösen" der Probleme im anderen Thread.

Vielleicht ein Problem mit CheckEqual?

Getestet per

Delphi-Quellcode:

procedure TestHashHEX;
  var
    strResultV3: ANSIString;
    strResultV5: ANSIString;
    cResult: Cardinal;
    FText: AnsiString;
  begin
    FText := 'This is a confidential ANSI Text';
    strResultV3 := '03BEBC72'; //Hash.THash_CRC32.CalcString(FText, nil, fmtHEX);

    cResult := CRCCalc(CRC_32CCITT, PAnsiChar(FText)^, Length(FText));
    strResultV5 := TFormat_HEX.Encode(cResult, 4);

    Memo1.Lines.Add(strResultV3);
    Memo1.Lines.Add(strResultV5);
  end;

und einem einfachen Memo.

Nachtrag: CheckEqualsString hat keine überladene Funktion für AnsiString. Vielleicht liegt hier irgendwo das Problem. Schreibt Dir selbst mal ein Overload dafür.

Ein einfaches

Delphi-Quellcode:

  if strResultv3 = strResultV5 then
      Memo1.Lines.Add('jup');

gibt mir jedenfalls in obigem Testcase ebenfalls das gewünschte "jup" aus.

Edit2:
Bei der Umstellung war ich doch nicht nachlässig: Ich habe gegen jeden Cipher, Hash und das Text-Encoding Vergleichstests gefahren. Teilweise automatisch (aus Part_I\DECTest) und auch manuell mit Testvektoren und Monte-Carlo-Tests (z.B. bei Rijndael mit Vorgaben vom NIST).

Anbei mal die Ergebnisliste aus dem DECTest. Die ist aber auch im DEC 5.2 mit dabei und mit D2009 erstellt.

Gruß Assertor

[ULIK]

Hi Assertor,
bei mir liefert dein Code keine Gleichheit (auch nicht in der IDE beim Debuggen). Vieleicht hab ich nur nicht die aktuellste Version des DEC 5.2 (meine Units sind alle vom 02.11.08 ). Kannst Du mir dafür einen Downloadlink geben?

Ergänzung: bei wird immer 'FFFFFF1F' als Ergebnis geliefert

Grüße,
Uli

[Assertor]

Hi Uli,

das Datum stimmt, aber trotzdem hier der Download-Link (bei Luckie): dec.michael-puff.de.

Probier mal das Problem zu isolieren, Du stehst wahrscheinlich voll im Testcase. Nimm mal ein leeres Form mit den DEC Units und einem Memo und teste Dein bzw. mein obiges Beispiel.

Ich schätze da fährt irgendeine Projekt-Einstellung oder Unit dazwischen.

Nachtrag (roter Kasten):

Problem nachvollziehbar:
DEC 5.2 mit D2009 und FastMM4 4.92 als Release-Build: ok
DEC 5.2 mit D2009 und FastMM4 4.92 als Debug-Build: FFFFFF1F (nur bei CRC, nicht den eigentlichen DEC Units)

Ich isolier das mal kurz, ob es ein FastMM4 oder an den Projekt-Optionen liegt.

Kannst Du das eben mal für DEC 5.x mit D2007 gegentesten, also Debugbuild und Releasebuild?

Gruß Assertor

[ULIK]

Hi,

Stimmt, Du hast recht: Delphi 2009 und Release Build und alles ist gut, Debug Build und es geht schief. Unter Delphi 2007 macht es keinen Unterschied, da gehen beide Versionen.

Grüße,
Uli

[Assertor]

Hi,

liegt an "Optimierung" in den Projektoptionen. Wenn die aus ist, geht es nicht - also kein Problem mit FastMM4.

Das wär also das einzige, was Du mal in D2007 prüfen könntest. CRC mit Projektoption Optimierung an und aus.

Die Sache hat nichts mit den DEC Hash/Format/Cipher Units zu tun. Die CRCCalc ist aus der CRC.pas und diese nutzt keinerlei Strings. Das ist so ziemlich die einzige Datei, die ich zu 100% übernehmen konnte.

Quick-and-Dirty-Workaround ist, im Header der Unit CRC.pas Optimization anzuschalten:

Delphi-Quellcode:

unit CRC;

{$OPTIMIZATION ON}
{$I VER.INC}
...

[Assertor]

Ok,

danke fürs Testen in D2007. Damit Du auch benachrichtigt wirst ein neuer Eintrag, kein Edit

Es betrifft die CRC_32CCITT, nicht z.B. CRC_32.

cResult := CRCCalc(CRC_32, PAnsiChar(FText)^, Length(FText));

liefert mit/ohne Optimization immer C1271A8C.

Also schau ich mir CRC_32CCITT mal an.

Gruß Assertor

[ULIK]

Oh Mann, darauf muß man erst mal kommen! Unter Delphi 2007 macht's übrigens keinen Unterschied, ob die Optimierung an oder aus ist.

Vielen Dank für deine Hilfe!
Uli

[Assertor]

Zitat von ULIK:

Oh Mann, darauf muß man erst mal kommen!

Sind wir doch

Zitat von ULIK:

Unter Delphi 2007 macht's übrigens keinen Unterschied, ob die Optimierung an oder aus ist.

Ok und Danke für das Prüfen.

Zitat von ULIK:

Vielen Dank für deine Hilfe!

Gerne!

Ich prüf gerade mal etwas rum, ich vermute die CRC Init muß genutzt werden. Sobald ich was hab, poste ich hier. Kann natürlich auch ein besonderes Compiler/Linker-Verhalten von D2009 sein (muß mal im QC schauen).

Gruß Assertor

[ULIK]

Jup, soweit ich gesehen hab unterscheiden sich die Werte vom CRC nach Aufruf CRCInit (in CRCCalc). Da wird die Lookup-Tabelle nicht gefüllt.

Grüße,
Uli