Frage zu den "neuen" Records in 10.4

[jaenicke]

Zitat von Der schöne Günther:

Zitat von jaenicke:

Wenn sie in irgendeiner Version einmal nicht mit kopiert wurden, war das ein Bug.

Tatsächlich? Ich war die letzten Jahre auf 10.0 Seattle, und da wurden die Padding-Bytes bei einer Zuweisung definitiv nicht mitkopiert. Zu anderen Versionen kann ich nichts sagen. Ist ja auch eigentlich eine gute Sache dass es (jetzt) so ist.

Ich habe nun in einer VM Delphi 10.0 ausprobiert. Auch da werden alle Bytes kopiert.

Beispielcode:

Delphi-Quellcode:

var
  test: PByte;
begin
  a.someByte := 1;
  a.someInteger := 1;
  test := @a.someByte;
  Inc(test);
  test^ := 42;
  b := a;
  test := @b.someByte;
  Inc(test);
  ShowMessage(IntToStr(test^));

Egal ob lokale Variablen oder globale Variablen, es kommt immer 42 heraus...

[Der schöne Günther]

Tut mir leid für den vielen Aufwand den ich verursacht habe. Das hätte sich vermeiden lassen wenn ich erst einmal geschaut hätte was an meinen Tests genau fehlgeschlagen ist. Dann hätte ich auch nicht unsinnige Schlüsse gezogen wie dass bei einer Zuweisung das Padding nicht mitkopiert werden würde.

Um genau zu sein ging es um Padding-Bytes am Schluss eines Records. Beispiel:

Delphi-Quellcode:

TPaddingAtEnd = record
  a:   Integer;
  b:   Byte;
end;

Hier war unter 10.4 das Padding hinten immer 0xFF und in den Tests wurde dann das Padding bei Record A auf 0xFF gesetzt und erwartet dass die Bytes ungleich waren mit denen von Record B. In 10.0 scheint das Padding hinten allerdings wie erwartet zufällig zu sein.

Für die ganz interessierten:

Delphi-Quellcode:

paddingAtEnd1.a := 10;
paddingAtEnd1.b := 99;
paddingAtEnd2 := paddingAtEnd1;
TRecordHelper.FillPaddingBytes(paddingAtEnd1, $FF);
CheckFalse( isBytewiseEqual(paddingAtEnd1, paddingAtEnd2) );

wobei

Delphi-Quellcode:

function TestRecordHelper.isBytewiseEqual<T>(const a, b: T): Boolean;
var
   comparer: IEqualityComparer<T>;
begin
   comparer := TEqualityComparer<T>.Default();
   Result := comparer.Equals(a, b);
end;

Das CheckFalse(..) schlug jetzt in 10.4 fehl da die beiden paddingAtEnd -Records schon von Anfang an am Schluss FFs hatten. Ich habe das Muster in den Tests jetzt gegen 0xAA, 0xBB usw getauscht und die Welt scheint wieder in Ordnung zu sein.

[jaenicke]

Ich hatte dort auch schlicht angeschaut was genau bei der Zuweisung im Speicher passiert, auch bei einem größeren Record:


Dort kann man sehr gut sehen, dass die 42=$2A mitkopiert wird und auch warum (zweimal mov auf 4 Byte).

[himitsu]

Hier wird direkt ein MOVE reinoptiermiert, da der Record klein ist und keine "schlimmen" Typen ethält.

Nimm für den Test auch mal einen String, Interface, Variant oder DynArray mit in den Record auf,
damit die CopyFunktionen aus System benutzt werden. (CopyRecord, bzw. CopyArray mit Länge 1)

[Der schöne Günther]

Ja, hier war wieder ein einfaches Weltbild am Werk, gemanagte Typen kommen in den Tests gar nicht vor. Danke! 👍