TStream.ReadBuffer schlägt fehl

[Benmik]

Ich verwende in einem 64-Bit-Programm die Prozedur TFile.ReadAllBytes , die letztlich in System.Classes TStream.ReadBuffer landet. Die Zeile LTotalCount := Read(Buffer, Offset, Count); schlägt fehl, denn Count beträgt 2.446.468.450 Bytes, LTotalCount -1.848.498.846 Bytes. LTotalCount ist deklariert als NativeInt, also Int64; High(LTotalCount) = 9.223.372.036.854.775.807 ein Überlauf kann es also ja wohl nicht sein.

Gefunden habe ich das hier, aber das ist doch wohl nicht der Grund, oder?

[Sinspin]

Die Antwort klingt logisch.
Lokale Variablen als Puffer machen auch schon unter 32Bit unter Umständen Probleme. Zm beispiel wenn man sie sich mit Dll's teilt. Ich denke mal das es dort aber eher Scope Probleme sind. Denn die Variablen landen ja auf dem Stack.
Man müsste wohl die Variable auf dem Stack dann passend ausrichten das sie ins Muster passt. Oder sich einfach einen Puffer anlegen.

[Benmik]

Hab ich jetzt nicht verstanden. Meinst du, das von David Heffernan angesprochene Non-Alignment-Problem ist auch hier die Ursache? Emba legt den Puffer mit einem simplen SetLength an. Heißt das, dass der Puffer dann nicht notwendigerweise ausgerichtet ist und dass Emba sich darum nicht kümmert? Selbst wenn - wieso kommt dann ein negatives Ergebnis heraus?

EDIT: Ich habe nun den Test gemacht, den Speicher selbst zu reservieren, und zwar mit

Delphi-Quellcode:

var TB:TBytes;
begin
SetLength(TB, 4778259 * 512);

Und siehe da, Delphi meldet Overflow. Aber wieso? Selbst nach diesem Beitrag von 2009 müsste die Obergrenze 2 * LongInt sein, was hier ja nicht überschritten wird (und was nicht berücksichtigt, dass LongInt unter 64-Bit Int64 sein sollte).

[Stevie]

Zitat von Benmik:

Die Zeile LTotalCount := Read(Buffer, Offset, Count); schlägt fehl, denn Count beträgt 2.446.468.450 Bytes, LTotalCount -1.848.498.846 Bytes. LTotalCount ist deklariert als NativeInt, also Int64; High(LTotalCount) = 9.223.372.036.854.775.807 ein Überlauf kann es also ja wohl nicht sein.

Mal geguckt, was Read für'n Rückgabetyp hat und welchen Typ der Count Parameter hat?

[Benmik]

Zitat von Stevie:

Mal geguckt, was Read für'n Rückgabetyp hat und welchen Typ der Count Parameter hat?

Ja, Count hat NativeInt und der Rückgabewert von Read ist LongInt.
Aber wie ich inzwischen geschrieben habe, geht bereits die Dimensionierung von TBytes nicht.

[Sinspin]

Hmmm. Eigentlich geht es um die Anfangsadresse des Puffers im Speicher. Das wird aber eigentlich mit der Byteausrichtung schon programmtechnisch gelößt. Nur bei Variablen auf dem Stack nicht.
Verwende mal eine Variable im Objekt (oder global) und nicht lokal in der Procedure.

Das was da in dem Beispiel behandelt wird ist ein Sonderfall. Trotzdem erschließt sich mir nicht warum das Sector Alignment auf 512 Bytes im Memory, selbst für shared read / write.
Allerdings stimmt nach der Ausrichtung auf 512 Byte auch das auf 4 oder 8 Byte. Was eigentlich reichen sollte.

[Sinspin]

Zitat von Benmik:

Und siehe da, Delphi meldet Overflow. Aber wieso? Selbst nach diesem Beitrag von 2009 müsste die Obergrenze 2 * LongInt sein, was hier ja nicht überschritten wird (und was nicht berücksichtigt, dass LongInt unter 64-Bit Int64 sein sollte).

Nein. Das wandert in deinem Fall auf den Stack. Das wird nix.

Drück in deinen Programm mal STRG+O+O. Dann steht oben in der Unit ne masse Zeug.
Unter anderem sowas: {$MAXSTACKSIZE $00100000} Das ist die maximal mögliche Stackgröße deines Programms. TB passen da nicht drauf.

[BerndS]

Eigentlich sollte nur der Zeiger des Arrays im Stack liegen. Setlenght nimmt den Speicher vom Heap. Sonst müsste ein Stackoverflow kommen.

[Benmik]

Irgendwie kapiere ich es nicht. Wenn ich SetLength(TB, 4778259 * 512) verwende, dann meldet Delphi E2099 Overflow in conversion or arithmetic operation . Setze ich dagegen 2446468450 ein, verschwindet der Fehler, und auch High(Int64) wird klaglos akzeptiert.

Verwende ich FileStream.Read64 , geht es (man sieht aber in System.Classes, dass dann in Portionen von 512 MB eingelesen wird). Bei der Verarbeitung kommt dann doch noch ein Fehler, von dem ich aber nicht weiß, ob es etwas mit dem Puffer zu tun hat.

Jedenfalls sehr unangenehm, dass man sich nicht auf ReadAllBytes verlassen kann. Hat Jahre gedauert, ehe ich auf den Fehler aufmerksam wurde.

[Stevie]

Zitat von Benmik:

Zitat von Stevie:

Mal geguckt, was Read für'n Rückgabetyp hat und welchen Typ der Count Parameter hat?

Ja, Count hat NativeInt und der Rückgabewert von Read ist LongInt.

Hoecker, sie sind raus. (siehe Screenshot im Anhang)

Das ist leider eine der vielen Stellen, die unter 64bit ein bissle defekt sind. Der Count Parameter von ReadBuffer is zwar NativeInt, aber net der von Read. Somit passiert hier nen impliziter Cast mit potenziellem Datenverlust. Und wenn alles ziemlich in die Hose geht, übergibt man da nen Integer, bei dem das höchste bit 1 ist (weils nunmal die unteren 32bit des 64bit NativeInts sind) was einen negativen Integer ergibt.

Aber weil ja alles abwärtskompatibel sein muss, kann man diese Bugs in den Signaturen nicht so einfach fixen.

TFile.DoReadAllBytes ist übrigens auch schon defekt, denn LFileStream.Size ist Int64, aber auf 32bit kann man nur einen Integer an SetLength übergeben. Da die RTL aber ohne Range und Overflow checks gebaut wird, passiert hier potenziell dasselbe wie oben erklärt, wenn ich unter 32bit ne Datei lesen möchte die größer als 2^31-1 Bytes ist, dann landet hier Grütze im SetLength und es kommen irgendwelche Fehler aber sicher kein "Hey die Datei is zu groß"

Wenn Embarcadero beim Kompilieren ihres Sourcecodes W1071-W1073 anschalten würde, dann würds aufleuchten wie nen Weihnachtsbaum.