DEC 5.2 Fehler unter Delphi 2009 (?)

[Assertor]

Zitat:

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

Richtig, dabei hat Hagen da schon extra Code drin für den Optimization-Fall. :?: Mal sehen, das bekommen wir hin. Das ist dann aber eher ein D2009 Problem als ein DEC Problem (wie gesagt, die Unit ist ja hauptsächlich ASM und arbeitet ohne String und wurde nicht geändert).

Gruß Assertor

[Assertor]

Lösung ist, die gesamte CRCInit() in eine Zwang-Optimierung zu setzen, anstatt nur die CRCTab:

Delphi-Quellcode:

{$IFOPT O-}{$O+}{$DEFINE NoOpt}{$ENDIF}
function CRCInit(var CRCDef: TCRCDef; CRCType: TCRCType): Boolean; register;
type
  PCRCTab = ^TCRCTab;
  TCRCTab = array[TCRCType] of packed record
    Poly,Bits,Init,FInit: Cardinal;
    Inverse: LongBool;
  end;

  procedure CRCTab;
  asm
    //    Polynom   Bits InitVec    FinitVec   Inverse
    DD    $000000D1,  8, $00000000, $00000000, -1   // CRC_8  GSM/ERR
    DD    $00000233, 10, $00000000, $00000000, -1   // CRC_10 ATM/OAM Cell
    DD    $0000080F, 12, $00000000, $00000000, -1   // CRC_12
    DD    $00008005, 16, $00000000, $00000000, -1   // CRC_16 ARC,IBM
    DD    $00001021, 16, $00001D0F, $00000000,  0   // CRC_16 CCITT ITU
    DD    $00008408, 16, $00000000, $00000000, -1   // CRC_16 XModem
    DD    $00864CFB, 24, $00B704CE, $00000000,  0   // CRC_24
    DD    $9DB11213, 32, $FFFFFFFF, $FFFFFFFF, -1   // CRC_32
    DD    $04C11DB7, 32, $FFFFFFFF, $FFFFFFFF, -1   // CRC_32CCITT
    DD    $04C11DB7, 32, $FFFFFFFF, $00000000, -1   // CRC_32ZModem

    // some other CRC's, not all yet verfied
    // DD    $00000007,  8, $00000000, $00000000, -1   // CRC_8  ATM/HEC
    // DD    $00000007,  8, $00000000, $00000000,  0   // CRC_8 the SMBus Working Group
    // DD    $00004599, 15, $00000000, $00000000, -1   // CRC_15 CANBus
    // DD    $00001021, 16, $00000000, $00000000,  0   // CRC_16ZModem
    // DD    $00001021, 16, $0000FFFF, $00000000,  0   // CRC_16 CCITT British Aerospace
    // DD    $00004003, 16, $00000000, $00000000, -1   // CRC_16 reversed
    // DD    $00001005, 16, $00000000, $00000000, -1   // CRC_16 X25
    // DD    $00000053, 16, $00000000, $00000000, -1   // BasicCard 16Bit CRC (sparse poly for Crypto MCU)
    // DD    $000000C5, 32, $00000000, $00000000, -1   // BasicCard 32Bit CRC
  end;

begin
  with PCRCTab(@CRCTab)[CRCType] do
    Result := CRCSetup(CRCDef, Poly, Bits, Init, FInit, Inverse);
end;
{$IFDEF NoOpt}{$O-}{$ENDIF}

Dann geht es immmer. Sehr gediegenes Verhalten der Optimization, aber naja...

Gruß Assertor

[ULIK]

Super! Funktioniert und es gibt einen glücklichen Menschen mehr! :xmas:

Grüße,
Uli

[Assertor]

Zitat:

Zitat von ULIK

Super! Funktioniert und es gibt einen glücklichen Menschen mehr! :xmas:

Super! Dann nehm ich das gleich in das Package auf und mail es Luckie :)

:xmas: Und falls man vorher nicht mehr von einander liest: Ich wünsche ein frohes Weihnachtsfest und erholsame Feiertage! :xmas:

Gruß Assertor

[ULIK]

Wünsch ich ebenso!

Uli :xmas:

[negaH]

Jaja, so ist das mit den krummen Tricks der Programmierer. Die "Procedure" CRCTab ist ja nichts anderes als eine Datentabelle die im Codesegment der Anwendung liegen soll (Zugriffsrechte etc.pp). Normalerweise hätte man auch ein normales konstantes Array[] im Datensegment ablegen können und diese Probleme mit der unvorhersagberen Resultaten der Optimierungen des Compilers hätten keinerlei Auswirkungen gehabt.

Es scheint also so zu sein das lokale Compilerswitches je nach Delphi Version unterschiedlich behandelt werden, was ja auch nicht so sein sollte, wegens Abwärtskompatibilität.

Gruß Hagen

[Luckie]

Die aktuelle Version mit dem Bugfix ist auch auf meiner Seite zu haben: http://dec.michael-puff.de

[Assertor]

Hi,

@Luckie: Danke :)

Zitat:

Zitat von negaH

Jaja, so ist das mit den krummen Tricks der Programmierer. Die "Procedure" CRCTab ist ja nichts anderes als eine Datentabelle die im Codesegment der Anwendung liegen soll (Zugriffsrechte etc.pp). Normalerweise hätte man auch ein normales konstantes Array[] im Datensegment ablegen können und diese Probleme mit der unvorhersagberen Resultaten der Optimierungen des Compilers hätten keinerlei Auswirkungen gehabt.

Es scheint also so zu sein das lokale Compilerswitches je nach Delphi Version unterschiedlich behandelt werden, was ja auch nicht so sein sollte, wegens Abwärtskompatibilität.

Richtig, Du *Trickser* ;) Wär es jetzt in einem ASM inline passiert, wo irgendwo mit Chars bzw. einer festen Länge für selbige hantiert wird, hätte ich es ja noch verstanden, aber bei einem einfachen Befüllen per DD ist das schon merkwürdig. Das mit dem Array hatte ich mir gestern auch überlegt.

Ein neues D2009 Feature: Code wird wegoptimiert, wenn die Optimierung aus ist.

Gruß Assertor

[negaH]

naja der Grundgedanke dabei war ja alles im CS abzulegen. Und benutzt man die zwei preinitialisierenden CRC Funktionen nicht so benötigt die gesammte CRC Unit ausschließlich nur das Codesegement. Da das CS unter Win strengeren Zugriffsrechten unterliegt und die CRC.pas im kryptographischen Kontext eine wichtige Unit zur Überprüfung der anderen Units darstellt, dachte ich mir das diese wichtigen Initialisierungsdaten im CS am besten aufgehoben wären. Ich weiß das dies nur eine kleine Hürde für einen gewillten Angreifer darstellt. Fazit: Aufwand & Nutzen stimmt nicht mehr wenn man die inkompatibilitäten durch Borland mit berücksichtigt.

Gruß Hagen

PS: aus dieser Sicht ärgere ich mich ja über mich selbst.