TStream.ReadBuffer schlägt fehl

[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).

[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.