Spezielles CRC-16: Übersetzung aus C++ (omg)

[gammatester]

Zitat von Muetze1:

Zitat von gammatester:

Allerdings scheint mit der Code nicht sehr sinnvoll, da erstmal zwei Blöcke mit Zeichen >= ' ' überlesen werden. Wenn man die Beispieldatei wörtlich nimmt, würden also Automatic save #1 und Initial value: 196 überlesen und die CRC-Berechnung startet mit dem #13#10 danach.

Nein, "Initial value" wird schon mit einberechnet, da "Automatic save #1" schon zwei Leerzeichen hat. Er fängt also die CRC Berechnung mit dem "#" von "#1" an.

Das seh ich anders: Die erste while-Schleife verwirft alles bis 'Automatic save #1'#13 und endet weil #13<' ', die zweite while-Schleife liest #10 und endet. Also müßte doch mit 'Initial value: 19'#13#10 begonnen werden (anders als in meinem ersten Beitrag).

Gruß Gammatester

[Muetze1]

Zitat von gammatester:

Das seh ich anders: Die erste while-Schleife verwirft alles bis 'Automatic save #1'#13 und endet weil #13<' ', die zweite while-Schleife liest #10 und endet. Also müßte doch mit 'Initial value: 19'#13#10 begonnen werden (anders als in meinem ersten Beitrag).

Ja, das ist richtig. Ich hatte vorhin auch ein Denkfehler von wegen >= ' ' und > ' '. Aber deine letzte Aussage ist nun korrekt, die unterschreibe ich so mit...

[blackdrake]

Hallo.

Vielen Dank für eure Hilfe. Ihr habt mir sehr geholfen!

Zitat von Muetze1:

Ich habe bei dem Code zuvor eigenmächtig eine Optimierung gemacht, die aber zu einem falschen Ergebnis führt. Von daher habe ich oben den Code korrigiert. Bitte den Code erneut ausprobieren.

Deine Veränderung hatte ich bei dem Codevergleich C/Delphi zwar bemerkt, aber ich hatte ebenfalls nicht erkannt, dass durch die Ausklammerung des "AResult SHL 1" die If-Abfrage beeinflusst wird. Mit dem korrigierten Code wird nun die Prüfsumme korrekt wie im Originalprogramm berechnet.

Zitat von gammatester:

Das CRC-Polynom ist das altbekannte CRC-16-CCITT (Dein Code benutzt den Startwert $FFFF statt wie meist $0000);

Gut, zu wissen, wie der Algorithmustyp genau heißt. Danke für den Hinweis. Trotzdem scheint mir die Funktion ein Exot zu sein, da der Programmierer auch irgendetwas mit dem Wert $1021 (als "Poly") macht

Zitat von Muetze1:

Nein, "Initial value" wird schon mit einberechnet, da "Automatic save #1" schon zwei Leerzeichen hat. Er fängt also die CRC Berechnung mit dem "#" von "#1" an.

Ich verstehe dieses ganze mit dem >= '' nicht wirklich. Es werden scheinbar die ASCII-Werte des Chars verglichen. Ich konnte aber wie gesagt mit dem Delphi-Code durch showmessage(lData); innerhalb der While-Schleife nachweisen, dass der CRC tatsächlich mit "Initial value" beginnt. Das ist auch absolut korrekt so, da die erste Zeile der Dateikopf ist und nach dem # die CRC-Summe als Dezimal stehen muss.

Der originale C-Code mit dem >= '' erscheint mir irgendwie etwas unprofessionell. Hätte man besser lösen können. Es ist für dritte Personen ohne Debugging-Tools unklar zu erkennen. Jetzt, wo ich die Prüfsummen jedoch korrekt berechnen kann, kann ich die Funktionen für Stringeingaben anstelle von Dateieingaben anpassen.

Gruß
blackdrake

[gammatester]

Zitat von blackdrake:

Gut, zu wissen, wie der Algorithmustyp genau heißt. Danke für den Hinweis. Trotzdem scheint mir die Funktion ein Exot zu sein, da der Programmierer auch irgendetwas mit dem Wert $1021 (als "Poly") macht :?

Was da "gemacht" wird ist folgendes: Ein Zeichen wird bitweise durch den Algorithmus gedreht und wenn's ein Carry gibt, wird das Polynom "subtrahiert" (= xor). Normalerweise berechnet man die CRCs mit Hilfe von Tabellen (je ein Eintrag für ein Byte), hier

Delphi-Quellcode:

  ctab: array [0..255] of word =
          ( $0000, $1021, $2042, $3063, $4084, $50A5, $60C6 ...

Der CRC-Code ist kein Exot, sondern das worüber der CRC berechnet wird. Gibt es eigentlich einen Link oder so auf den Original-C++-Code?

Gruß Gammatester

[blackdrake]

Hallo. Ja, der Code stammt von http://users.tmok.com/~pla/lychrel/lychrel.shtml (isft2757.zip). Ein Utility mit dem man ISF-Dateien auf Validität prüft. (= Inoffizieller Standard für Computingsoftware, die Lychrel Zahlen lösen soll)

[gammatester]

Zitat von blackdrake:

Hallo. Ja, der Code stammt von http://users.tmok.com/~pla/lychrel/lychrel.shtml (isft2757.zip). Ein Utility mit dem man ISF-Dateien auf Validität prüft. (= Inoffizieller Standard für Computingsoftware, die Lychrel Zahlen lösen soll)

Ich hab das Teil mal gesaugt und auf Dein ISF losgelassen. Für das Original gibt es eine Fehlermeldung (CRC im File sei 1). Wenn man den Code von Muetze1 laufen läßt, ergibt sich ein CRC von 23030, trägt man diesen Wert in Zeile 1 ein, dann meldet ISFTool "File has correct CRC-16, 59F6". Hinweis: 23030 = $59F6.

Automatic save #23030
Initial value: 196
Iteration: 1594
Number of digits: 660
22333910958872264892526694002930979289683139938521 78183738667668494442
94922125263844861806482566226428100603060667838635 77455348324982112153
27151358088414882529028698044772290973987100106291 19577823823636994210
42161726883090631964313670119973413725817442334009 75666507297914430210
49065199007066009777588207096089472059352744630955 56013643625406027389
15907117967778995608099024608401312351880369466658 00933324481763731427
00210763134591270912796181611511239072532941777602 09360100069046919128
74397969299351785138907640527235121118052285355368 62593777696129500193
46226651747082574494614212304824449596676682738178 21493904138589288012
820049673518847316886010834312


Zu beachten ist, daß ISFTool den CRC in dezimal ab Spalte 17 erwartet.

Gruß Gammatester

[blackdrake]

Zitat von gammatester:

Zu beachten ist, daß ISFTool den CRC in dezimal ab Spalte 17 erwartet.

Hallo.

Mit dem CRC-16-Test bin ich schon komplett durch. Das mit der 17ten Stelle weiß ich auch. Ich hatte in der originalen Datei den CRC-Wert 1 gesetzt, weil mein Programm, das die ISF geschrieben hat, zu diesem Zeitpunkt nicht ISF-Konform war. Jetzt habe ich ja den korrekten Algorithmus und kann daher Dateien valid lesen und schreiben.

Gruß
blackdrake