PureBoard

Tachchen,

da ich inzwischen auch an einem 64-Bit System testen kann, bin ich auf folgendes problem gestoßen:

CRC32Fingerprint gibt eine Integer zurück, statt einer Long.
In meinen eigenen Dateien speicher ich 32-Bit Fingerabdrücke immer als LONG und lese sie auch als Long ein.
Wenn ich sie nun aber mit der Funktion unter 64Bit-Windows vergleiche, ist das Ergebnis immer positiv, nicht wie in 32-Bit, dass die Long ein Vorzeichen besitzt.
Das Problem ist also, dass er viele Datei als beschädigt einstuft.

32-Bit hat geschrieben:-1441790254

64-Bit hat geschrieben:2853177042

Bleibt mir nun nichts anderes übrig als immer ein & $FFFFFFFF zu benutzen, damit unter 64Bit, das Vorzeichen vernichtet wird?

STARGÅTE hat geschrieben:da ich inzwischen auch an einem 64-Bit System testen kann, bin ich auf folgendes problem gestoßen:

CRC32Fingerprint gibt eine Integer zurück, statt einer Long.

Wenn Du es in eine Long-Variable speicherst, dann geht es. Die Hilfe vom neuen PB4.60 zeigt leider nicht den Typ an, der zurückgegeben wird.
Somit sollte es Integer sein, aber es wäre wünschenswert, wenn das PB-Team und
die Hilfeschreiber den Rückgabetyp überall wirklich angeben.

Unabhängig davon generiert Dein original Code:wohl auch einen anderen CRC32 weil die Variable 'Buffer' Integer ist (da keine Typangabe),
und somit ist die Variable einmal 32bit und einmal 64bit.
Die Funktion rufst Du dann aber mit Size 4 auf, was mit PB 64bit nur den halben
Buffer nimmt.

Mit meinem obigen Code solltest Du weiter kommen, also den Rückgabewert direkt
in einer Long-Variable speichern.
Macht ja Sinn das CRC32 einen 32bit-Wert zurückgibt. Sollte in der Hilfe erwähnt werden.

Das sollte aber richtig funktionieren: Gibt aber unterschiedliche Werte. Sieht aus wie ein Bug, denn der
32bit Rückgabewert der Funktion sollte so automatisch nach Integer
konvertiert werden.

Somit hast Du Recht! In Deinem Code war nur noch dieser zusätzliche Fehler drin.
Scheint ein Bug in der Funktion (oder deren Library-Deklaration) und in der Hilfe zu sein.

Damit hast Du den ersten offiziellen Bug für 4.60 Final gefunden. Glückwunsch!

Das der Buffer wegen i unter 64Bit größer ist, ist nicht schlimm, da ja sowieso in den ersten 4 Byte die hinteren Stellen gespeichert werden, also eben gerade die 1234.

Im Prinzip ist es auch kein Bug in dem Sinne, dass was falschen zurückgegeben wird.
Es wird ja in beiden Fällen das selbe 32-Bit-Muster zurückgegeben, nur wird es anders interpretiert.

Problematisch wird es erst dann, wenn ich es wirklich als LONG speicher, dann aber im Kompiler mit einer Integer verglichen wird, da diese ja dann die Zahlen über 2^31 positiv darstellt, statt wie Long negativ.

Blöd wäre zudem, wenn die Funktion nun umgeschrieben wird, und es immer eine Long zurück gibt, dass dann andere Codes nicht mehr Funktionieren. zB weil jemand unter 64Bit immer als Quad gespeichert hat, und nun ebenfalls verschieben werte vergleicht.

Allerdings bin ich der Meinung, dass CRC32Fingerprint wirklich immer Long als Speichermedium nutzen sollte.

Jemand anderer Meinung?

STARGÅTE hat geschrieben:Allerdings bin ich der Meinung, dass CRC32Fingerprint wirklich immer Long als Speichermedium nutzen sollte.

Das meinte ich ja. Deshalb muss der folgende Code mit PB x32 und PB x64 jeweils immer
das gleiche Ergebnis ausgeben: Macht es aber nicht, also IMO ein Bug. Der 32bit Rückgabewert wird bei x64 nicht in ein Integer konvertiert,
sonst wäre der Long-Wert '-1441790254' danach als Integer auch noch '-1441790254'.

Normal funktioniert das ja auch: Nur eben bei CRC32Fingerprint() nicht, also ein Fehler. CRC32 muß ein Long zurückgeben, CRC16 ein Word.

Habs trotzdem erst mal als Frage ins engleiche Forum gestellt.