Verständnisfrage offene Arrays, move und setlength

[kmma]

Gegeben sei folgendes Konstrukt:

Delphi-Quellcode:

type Tx = packed record
    a: integer;
    b: integer;
    end;
type TY = packed record
    c: integer;
    d: integer;
    end;
type TRec = packed record
    X: array of Tx;
    Y: array of TY;
    end;
var R: TRec;

Was passiert genau, wenn ich jetzt etwas mehr oder weniger willkürliches in R per "move" schiebe?

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
    var x, sr, lx, ly, vx: integer;
begin
    sr := sizeof(R); // 8
    x := integer(@x);  // irgendeine Adresse
    move(x, R, 8);
    lx := length(R.x);  // zufällige Zahl, hier ziemlich groß
    ly := length(R.y);
    vx := R.x[1].a;  // geht
    vx := R.x[lx - 1].a; // Zugriffsverletzung beim lesen

Ich vermute, dass der erste Zugriff (R.x[1].a) noch geht, weil sich dieser Wert noch in meinem Speicherbereich befindet, der zweite Zugriff (vx := R.x[lx - 1].a) aber nicht weil die Adresse davon außerhalb meines Speichersegmentes liegt.
Stimmt das soweit?

Delphi-Quellcode:

    
    lx := length(R.x);  // zufällige Zahl
    // fillchar(R, sizeof(R), 0); // mit fillchar alles ok, ohne Crash
    setlength(R.x, 100000);

Wenn ich jetzt direkt versuche, die Größe des Array zu ändern crasht das ganze wieder. Ich vermute, dass hier Speicher freigegeben würde, der mir nicht gehört. Ist das richtig?
Wenn ich mit fillchar meine Variable R aber zuvor auf 0 setze geht wei erwartet alles. Die Frage ist hier: Habe ich in der Zwischenzeit schon irgendeine Verletzung vorgenommen?
Sprich wird nur mit der (zugegebenermaßen sinnlosen) Zuordnung

Delphi-Quellcode:

    move(x, R, 8);
    fillchar(R, sizeof(R), 0);

bereits irgendeine Verletzung vorgenommen oder werden da nur die 8 Byte, die für die Variable R reserviert sind, zweimal überschrieben und sonst passiert nichts?
Wird mit dem ersten move schon irgend ein Speicherbereich verändert außer den 8 Byte die zu "R" gehören?
Mir geht es rein um das Verständnis, nicht darum, ob der Code sinnvoll ist oder nicht.

[himitsu]

Zitat:

move(x, R, 8);

Wer das macht, gehört eh bestraft.

[kmma]

Zitat von himitsu:

Zitat:

move(x, R, 8);

Wer das macht, gehört eh bestraft.

Das war aber nicht meine Frage. Ich will wissen, ob ein "fillchar" das wie Du sagst zu bestrafende wieder kompensiert oder ob da schon etwas passiert ist.

[peterbelow]

Zitat von kmma:

Zitat von himitsu:

Zitat:

move(x, R, 8);

Wer das macht, gehört eh bestraft.

Das war aber nicht meine Frage. Ich will wissen, ob ein "fillchar" das wie Du sagst zu bestrafende wieder kompensiert oder ob da schon etwas passiert ist.

Wozu hast Du den Debugger? Geh schrittweise durch den Kode und sieh Dir den Inhalt und die Addressen der Variablen an.

Anyway: Wenn Du mit Datentypen arbeitest, für die der Compiler die Speicherverwaltung übernimmt soweit es ums Aufräumen geht, lass die Finger von low-level-Funktionen wie Move und Fillchar. Das betrifft die Typen String (Ansi und Unicode), Interfaces, dynamische Arrays, Widestring. Für solche Typen initialisiert der Compiler auch lokale Variablen (auch wenn sie Teil eines Records sind), sorgt bei Kopieroperationen (per Assignment oder Copy bei Arrays) für korrekte Behandlung des reference counts und gibt automatisch den belegten Speicher frei, wenn die Variable out of scope geht. Move und Fillchar umgehen all diese Mechanismen und führen dann zu Speicherlecks und AVs.

Lies den Delphi Language Guide! Der ist Teil der Onlinehilfe und enthält alle Infos über die Implementierung der diversen Datentypen die Du brauchst.

[himitsu]

Klar, würde ein FillChar mit 0 wieder ein leeres Array bereitstellen.

Aber wer weiß was bei dir wirklich vor dem Move/FillChar drin stand.
Am Ende hast'e im glücklichsten Fall bloß ein Speicherleck, weil DU die automatische Speicherverwaltung der dynamischen Arrays böswillig zerstört hast, ohne zu wissen wie Diese intern funktioniert.
(ich verrate besser mal nicht, dass es in System Records für die Verwaltungsdaten von LongStrings und dynamischen Arrays gibt, aber da Diese nicht öffentlich sind, sich Emba behaarlich weigert sie zu veröffentlichen und sie zuletzt auch auf unvorhersehbare Weise diese Arrays veränderten, ist es nicht einfach damit mit einer Kopie davon arbeiten zu wollen)

Zitat:

Delphi-Quellcode:

    x := integer(@x); // irgendeine Adresse
    move(x, R, 8);
    lx := length(R.x); // zufällige Zahl, hier ziemlich groß

Das "irgendeine" sagt es schon,
denn "zufällige Zahl, hier ziemlich groß" kann auch schnell irgendwas Anders sein, z.B. eine Zugriffsverlertzunh, wenn es an der Stelle keinen resservierten Speicher gibt.

Und wenn du jetzt auch noch irgendwas mit diesem Array machst, dann viel Spaß, wenn dieses "zufällige Zahl, hier ziemlich groß" irgendwas Wichtiges war, was du dabei eventuell überschreibst/zerstörst, ähnlich einem Bufferoverrun.

[Sinspin]

Anstatt uns über den Sinn des ganzen im Dunkeln zu lassen, könntest du uns einfach erleuchten und wir finden eine andere Lösung.

Zitat von himitsu:

Zitat:

move(x, R, 8);

Wer das macht, gehört eh bestraft.

Das ist einfach Herrlich. Danke Himitsu.
Ich würde aber weitergehen, das ist mutwillige Zerstörung von fremden Eigentum und gehört angekreidet. Zum Schluss erkennen dann wieder die Virenscanner alle Delhi Programme als Viren. Nur weil ein Verrückter wild im Speicher rumschreibt.

[Mavarik]

emm...

Was willst Du damit erreichen?

Mit dem gruseligen Move überträgst Du die Adresse von einer Variablen die auf dem Stack liegt in einen globale Variable.
Aber Sizeof(8) hätte dir hier schon einen Hinweis geben müssen, das dies so nicht passt.

Ein dynamische Array liegt auf dem Heap und bei -8 liegt die Referenz-Zählung und bei -4 die Länge...
Es ist also "nur" ein Pointer im Rekord.

Siehe : https://docwiki.embarcadero.com/RADS...ormate_(Delphi)

Wenn ich Deinen Source richtig verstanden habe...