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:

Delphi-Quellcode:

move(x, R, 8);

Wer das macht, gehört eh bestraft.

[kmma]

Zitat:

Zitat von himitsu (Beitrag 1520759)

Zitat:

Delphi-Quellcode:

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:

Zitat von kmma (Beitrag 1520763)

Zitat:

Zitat von himitsu (Beitrag 1520759)

Zitat:

Delphi-Quellcode:

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:

Zitat von himitsu (Beitrag 1520759)

Zitat:

Delphi-Quellcode:

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

[kmma]

Zitat:

Zitat von Sinspin (Beitrag 1520774)

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:

Zitat von himitsu (Beitrag 1520759)

Zitat:

Delphi-Quellcode:

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.

Inwiefern zerstöre ich fremdes Eigentum? Nach meinem Verständnis hat die Variable R die Größe 8 Byte und wenn ich da 8 Byte reinschiebe, was zerstöre ich dann?

Ich vruche es einmal zu erklären wie ich auf das Problem komme.
Ich bekomme aus einer externen Quelle, auf die ich keinen Einfluss habe (DLL), Datensätze, die wie folgt (vereinfacht) aufgebaut sind.

Delphi-Quellcode:

type TDatensatz = packed record
    Zahl1: integer;
    Beschreibung1: TStringlist;
    Zahl2: integer;
    Beschreibung2: TStringlist;
    ...
end;

In "Beschreibung" sind dann in jedem String im Klartext (ist eben so, kann ich nicht ändern) Untertypen beschreiben, z.B. "R=5; G=7; B=12"; "R=23; G=3; B=44" etc.

Um damit weiterarbeiten zu können möchte ich diese Datentypen in die folgende Struktur umwandeln:

Delphi-Quellcode:

type TUntertyp1 = packed record
    R: integer;
    G: integer;
    B: integer;
end;
type TUntertyp1Array = array of TUntertyp1;
type TMeinDatensatz = packed record
    Zahl1: integer;
    Untertyp1: TUntertyp1Array
    ...
end;

Da die Größe einer Stringlist und die Größe eines Array of TUnteryp (im packed Record) jeweils 4 Byte sind war meine Idee eben, die Daten aus TDatensatz zuerst 1:1 (per Move) in eine Veriable vom Typ TMeinDatensatz zu schreiben (sizeof(TMeindatensatz) und sizeo(TDatensatz) sind gleich groß) und dann die Größe von Untertyp1 auf die Anzahl der Strings in der Stringlist (Beschribung) zu setzen und dann im Untertyp die Felder mit einem Parser zu ermitteln. Dass ich nach dem kopieren der Daten nicht direkt auf den Untertyp zugreifen kann ist mir schon klar.
Die Frage ist eben, ob ich mit

Delphi-Quellcode:

var MeinDatensatz: TMeindatensatz;
move(Datensatz, Meindatensatz, sizeof(TMeindatensatz));
fillchar(MeinDatensatz.Untertyp1, 4,  0);
setlength(MeinDatensatz.Untertyp1, Datensatz.Beschreibung.count);
...

Irgendwas verbotenes mache oder ob das geht.

In diesem vereinfachten Besipiel könnte ich natürlich einfach die direkten Zuweisungen machen

Delphi-Quellcode:

MeinDatensatz.Zahl1 := Datensatz.Zahl1;
setlength(Meindatensatz.Untertyp1; Datensatz.Beschreibung.count);
...

In Wicklichkeit sind die Typen aber deutlich umfangreicher so dass mir eben die o.g. Idee als Vereinfachung gekommen ist.

[himitsu]

Und genau sowas macht man eben nicht, vor allem nicht bei gemangeten Typen, welche intern auch noch auf Pointer basieren.

Initialize
Finalize
:=
New
Dispose

InitializeRecord
InitializeArray
CopyRecord
CopyArray
MoveRecord
MoveArray
FinalizeRecord
FinalizeArray
...
Aber solche Funktionen ruft man eigentlich nicht direkt auf.



Und bei der einem Objekt (TStringList) hilft das alles sowieso nicht, da dort nichts managed ist.

[kmma]

Zitat:

Zitat von himitsu (Beitrag 1520805)

Und genau sowas macht man eben nicht, vor allem nicht bei gemangeten Typen, welche intern auch noch auf Pointer basieren.
...

Und bei der einem Objekt (TStringList) hilft das alles sowieso nicht, da dort nichts managed ist.

Ich glaube Du hast noch nicht verstanden, was ich eigentlich will. Ich will mit der Stringlist überhaupt nichts anfangen. Die will ich ganz sauber von Hand abarbeiten und in ein Array die passenden Werte schreiben.
Ich will die vielen 1:1 übertragbaren Werte (integer, boolean etc.) in einem Rutsch in meine Datenstruktur übernehmen und frage mich einfach nur, ob der eine Pointer (der auf einen Speicherberiech zeigen wird, der sehr wahrscheinlich mir nicht gehört) zwischen "move" und "fillchar" irgenwann dereferenziert wird.

Also um die Frage auf ein Langwort runterzubrechen:

Delphi-Quellcode:

type TDings = packed record
  a: integer;
  b: integer;
end;
type TDingsArray = array of TDings;
var Dings: TDings; //sizeof(Dings) = 4;
var CardVal: Cardial;
var p: pointer;

p := @Dings;
move(Dings, CardVal, 4); // Cardval = 0
move(p, CardVal, 4); // eben die Adresse
move(p, Dings, 4); // passiert da jetzt irgendwas mit Speicher der mir nicht gehört?
fillchar(Dings, 4, 0);  // um den Müll wieder loszuwerden
setlegth(Dings, 100);
move(Dings, CardVal, 4); // CardVal = Zeiger auf Array of TDings?

Ich glaube wenn ich die Zeile "move(p, Dings, 4);" weglasse sollte doch alles in Ordnung sein. Was ich wissen will ist, ob die Zeile "move(p, Dings, 4)" außer der Adresse @Dings .. @Dings + 3 noch einen Speicherbereich anspricht oder nicht.

[peterbelow]

Zitat:

Zitat von kmma (Beitrag 1520809)

Also um die Frage auf ein Langwort runterzubrechen:

Delphi-Quellcode:

type TDings = packed record
  a: integer;
  b: integer;
end;
type TDingsArray = array of TDings;
var Dings: TDings; //sizeof(Dings) = 4;

Stimmt nicht, Sizeof(Dings) ist 8, denn records sind value types, die Variable Dings enthält also keinen pointer sondern direkt die Daten des Records.

Delphi-Quellcode:

var CardVal: Cardial;
var p: pointer;

p := @Dings;
move(Dings, CardVal, 4); // Cardval = 0

Nach diesem Move enthält CardVal den Wert von Dings.a, nicht eine Adresse.

Delphi-Quellcode:

move(p, CardVal, 4); // eben die Adresse
move(p, Dings, 4); // passiert da jetzt irgendwas mit Speicher der mir nicht gehört?

Das erste Move schreibt den Wert von p (die Addresse von Dings) in die Variable Cardval (für 32 bit Target, für 64 bit wäre Sizeof(pointer) = 8, Sizeof(Cardval) aber 4)
Das zweite Move schreibt dann analog in Dings.a, d.h. nach den Move ist Pointer(Dings.a) = @Dings.

Delphi-Quellcode:

fillchar(Dings, 4, 0);  // um den Müll wieder loszuwerden
setlegth(Dings, 100);
move(Dings, CardVal, 4); // CardVal = Zeiger auf Array of TDings?

Das compiliert nicht da Dings ein TDings und kein TDingsArray ist.

Nehmen wir mal an, Dings wäre ein TDingsArray und Du hättest Platz für 100 TDings reserviert:

Delphi-Quellcode:

  SetLength(Dings, 100);

Nehmen wir weiter an, Du hättest irgend einen Puffer A mit 200 Integern und einen Pointer pA auf den Anfang dieses Puffers. Dann würde

Delphi-Quellcode:

Move(pA^, Dings[0], 200 * Sizeof(Integer));

den Inhalt des Puffers in den Dings array kopieren. Move verwendet typenlose Parameter, d.h. der Compiler übergibt hier die Addresse der übergebenen Variablen, deshalb muß pA dereferenziert werden und anstelle von Dings dessen erstes Element übergeben werden.

Delphi-Quellcode:

Move(pA^, Dings, 200 * Sizeof(Integer));

würde den Stack beginnend mit der Addresse von Dings mit 200 Integern überschreiben, definitiv nicht gut!

Delphi-Quellcode:

fillchar(Dings, 4, 0);  // um den Müll wieder loszuwerden

würde ein memory leak erzeugen; es überschreibt den vorher per SetLength erzeugten Pointer mit Nil, ohne den allokierten Speicher freizugeben.

Delphi-Quellcode:

Dings := nil;

oder 

SetLength(Dings, 0);

gibt den Speicher frei.

[himitsu]

Wie soll man auch verstehen was du willst?

OK, angeblich Einwas in was Anderes konvertieren,

aber auch jedes Mal schreibst du über unterschiedliche Strukturen
und nirgendwo war auch nur ansatzweise zu erkennen, wozu das Move überhaupt dienen sollte, außer dass du sinnlos eigenartiges Zeig umhermovest, was absolut keinen Sinn ergibt, außer dass damit die manchmal die Speicherverwaltung eines Dynamischen Arrays mit unpassenden Daten umgangen und vernichtet wurde und du dich danach dann beschwerst, dass es nun nicht mehr funktioniert, was aber auch vollkommen klar ist.

[dummzeuch]

Zitat:

Zitat:

Zitat von himitsu (Beitrag 1520759)

Zitat:

Delphi-Quellcode:

move(x, R, 8);

Wer das macht, gehört eh bestraft.

Das ist einfach Herrlich. Danke Himitsu.

Genau, stattdessen sollte man lieber ZeroMemory (Unit Windows) verwenden!!!!!111elf ;-)

Scherz beiseite:
(Denn ZeroMemory ruft nur wieder FillChar auf. Ich verwende trotzdem lieber ZeroMemory, weil es sprechender ist. Schließlich will ich ja einen Speicherbereich auf 0 setzen und nicht mit einem Zeichen füllen.)

Wenn man weiß, was man tut, ist die Verwendung von FillChar durchaus OK. Aber eben nur dann. Wer es trotzdem verwendet, sollte sich aber hinterher nicht beklagen, wenn er seltsame Effekte bekommt.