Fail - Experiment mit einem undokumentierten Sprachelement

[NicoDE]

Frage

Ich habe keine offizielle Dokumentation zu System.Fail (System.@Fail aka System._Fail, welche per Compiler-Magic aufgerufen wird) gefunden.
Falls jemand eine kennt, würde ich mich über einen Auszug freuen


Experiment

Meine Erwartungshaltung war, dass Fail entweder eine definierte Exception auslöst, oder der Konstruktor der Klasse nil zurück gibt.
Ich musste feststellen, dass ein beliebiger Speicherbereich ausgeführt wird - was meist schnell zu einer Zugriffsverletzung führt (aber nicht immer - wie der Zufall es will, ist mir genau dies passiert...).

Nehmen wir die einfache Klasse TBug und deren Konstruktor:

Delphi-Quellcode:

type
  TBug = class
    constructor Create();
  end;

constructor TBug.Create();
begin
  Fail;
end;

Der Compiler sollte dann (ungefähr) diesen Pseudo-Code für den Kontruktor generieren

Delphi-Quellcode:

function TBug_Create(VmtOrSelf: Pointer; Alloc: Boolean): TBug; register;
begin
  if Alloc then
     Result := System._ClassCreate(VmtOrSelf, Alloc)
  else
     Result := VmtOrSelf;

  Result := System._Fail(Result, Alloc);
  Exit;

  if Alloc then
    System._AfterConstruction(Result);
end;

Nun wird aber vom Compiler (Delphi 6) folgendes generiert (weicht je nach Compiler-Optionen etwas ab - aber das Problem bleibt):

Delphi-Quellcode:

function TBug_Create(VmtOrSelf: Pointer; Alloc: Boolean): TBug; register;
var
  _alloc: Boolean;
  _self: TBug;
asm
        // contructor's ENTER code
        test    dl, dl
        jz      @@NoAlloc
        add     esp, -10h
        call    System.@ClassCreate{Vmt, Alloc}
@@NoAlloc:

        // Save Alloc flag and Self pointer
        mov     [_alloc], dl
        mov     [_self], eax

        // Call Fail
        mov     dl, [_alloc]
        mov     eax, [_self]
        call    System.@Fail{Result, Alloc}
        jmp     @@Return

        // contructor's LEAVE code
        mov     eax, [_self]
        cmp     byte ptr [_alloc], 00h
        jz      @@NoAfter
        call    System.@AfterConstruction{Result}
        pop     dword ptr fs:[00000000h]
        add     esp, 0Ch
@@NoAfter:

        mov     eax, [_self]
@@Return:
end;

Falls man nun lange genug auf den Assembler-Code starrt, fällt einem auf, dass das Setzen des Exception-Handlers (pop dword ptr fs:[00000000h]) und das Zurücksetzen des Stackzeigers (add esp, 0Ch) leidlich vermisst werden - was im Endeffekt dazu führt, dass ein zufälliger Wert auf dem Stack von der ret-Anweisung als Rücksprungadresse verwendet wird (was meist zu einem Crash führt - es könnte sich dort allerdings auch eine Funktion zum Formatieren der Festplatte befinden).

Kurz, so wie Fail (in Delphi 6) implementiert ist, kann man nur dazu raten es nicht zu verwenden.


Gruß Nico

Nachwort: für Neugierige befindet sich im Anhang ein Testprojekt in dem Fail tatsächlich dafür sorgt, dass der Kontruktor nil zurück gibt (auf Details gehe ich hier erstmal nicht ein - genug Assembler für heute).

[jbg]

Zitat von NicoDE:

Kurz, so wie Fail (in Delphi 6) implementiert ist, kann man nur dazu raten es nicht zu verwenden.

Fail gehört ja auch nicht zu class sondern stammt noch aus Zeiten als object aktuell war. Und genau da gehört es hin:

Delphi-Quellcode:

type
  PTest = ^TTest;
  TTest = object
    constructor Init(f: Boolean);
    destructor Done;
  end;

constructor TTest.Init(f: Boolean);
begin
  if f then
    Fail;
  WriteLn('Init');
end;

destructor TTest.Done;
begin
  WriteLn('Done');
end;

var
  P: PTest;
begin
  P := New(PTest, Init(True));
  if P <> nil then
    Dispose(P, Done);
end.

[NicoDE]

Danke für die Aufklärung.

Dann könnte dieses Verhalten
a) irgendwo dokumentiert werden oder
b) in Klassenkonstruktoren vom Compiler abgewiesen werden
(schließlich gibt es ja eine entsprechende Fehlermeldung, dass System.Fail nur innerhalb von Konstruktoren zulässig sei - allerdings könnte der Hinweis, dass Objektkonstruktoren gemeint sind, nicht schaden...).

ps: da es sich bei meinem Beispielprojekt um einen Missbrauch des Sprachelements handelt, empfinde ich die Code-Library als 'falschen' Ort für dieses Thema.