Handling von Fehlern, Warnungen und Hints

[Dezipaitor]

Zitat von DeddyH:

Entweder definieren wir "global" unterschiedlich, oder Du irrst.

Delphi-Quellcode:

{$WARNINGS OFF}
procedure TForm1.Button1Click(Sender: TObject);
var i: integer;
begin
  for i := 1 to 5 do;
  ShowMessage(inttostr(i)); //hier kommt keine Warnung
end;
{$WARNINGS ON}

procedure TForm1.FormCreate(Sender: TObject);
var i: integer;
begin
  for i := 1 to 5 do;
  ShowMessage(inttostr(i)); //hier kommt eine Warnung
end;

Das sagt nichts aus.

Mit lokal ist gemeint, dass pro Unit die Warnungen ein-/ausgeschaltet werden können. D.h. sobald "end." erreicht wurde, werden Warnungen wieder auf standard gesetzt. z.B. {$WARN XY OFF/ON} hat diese Eigenschaft. Sie ist nur in der Unit gültig, in der sie definiert wurde und auch nur ab der Zeile.
Wenn du jedoch {$WARNINGS OFF} irgendwo in deinen 10000000 Units definierst, dann wird sobald der Compiler diese Stelle erreich, nie wieder eine Warnungen danach ausgegeben. Und schon hat man den Eindruck, dass es keine Warnungen gibt. Ist das nicht gefährlich? Ich sage: JA.


Außerdem hat dein Quelltext ein Problem. Wenn irgendwer Warnungen ausschaltet, aus welchem Grund auch immer, dann kommen nach der Zeile trotzdem Warnungen.

[calculon]

Na dann, in your face, alzaimar

Gruß
--

[SubData]

Ich seh das Problem immernoch nicht so wirklich.

Wenn mir die Warnungen von "fremden" Units zu doof sind, dann pack ich nur deren .dcu-Dateien mit ins Projekt, dass diese nicht neu compiliert werden und die .pas-Dateien werden zum Bibliothekspfad zu Delphi hinzugefügt und gut.

Somit kann ich in die Quellcodes reinschauen, hab aber keine Warnungen und keine Compilierung derselbigen...

[Dezipaitor]

Bei der JEDI API käme so ein besseres Warnungssystem wirklich gut an, da hier Warnungen ausgegeben werden, die nicht korrekt sind.

Beispiele:

Delphi-Quellcode:

var
  _AddSecurityPackageW: Pointer;

function AddSecurityPackageW;
begin
  GetProcedureAddress(_AddSecurityPackageW, secur32, 'AddSecurityPackageW');
  asm
        MOV     ESP, EBP
        POP     EBP
        JMP     [_AddSecurityPackageW]
  end;
end;

"Rückgabewert der Funktion AddSecurityPackageW könnte undefiniert sein" - Das ist hier falsch.
Hier ein "result := " einzufügen wäre wahnsinnig, da man ein paar tausend Funktionen anpassen müsste.

Weiterhin bekomme ich die Warnung "Unsicherer Code ASM". Die Vermutung ist falsch, da schon tausendfach erprobt.


Hier noch unsichere Typen. Verständlich warum Delphi diese als unsicher definiert. Aber letztendlich sind die C Definition so und Zeiger ohne Typ haben auch ihren Sinn, und daran kann man nichts ändern. Ich bekomme da auch mehrere tausend Warnungen ausgesprochen.

Zitat:

[Warnung] JwaWinType.pas(90): Unsicherer Typ 'Pointer'
[Warnung] JwaWinType.pas(93): Unsicherer Typ 'Pointer'
[Warnung] JwaWinType.pas(166): Unsicherer Typ 'Pointer'
[Warnung] JwaWinType.pas(170): Unsicherer Typ 'Pointer'
[Warnung] JwaWinType.pas(234): Unsicherer Typ 'PAnsiChar'
[Warnung] JwaWinType.pas(238): Unsicherer Typ 'PAnsiChar'
[Warnung] JwaWinType.pas(168): Unsicherer Typ 'PVOID'
[Warnung] JwaWinType.pas(315): Unsicherer Typ 'PAnsiChar'
[Warnung] JwaWinType.pas(322): Unsicherer Typ 'LPSTR'
[Warnung] JwaWinType.pas(323): Unsicherer Typ 'LPSTR'
[Warnung] JwaWinType.pas(325): Unsicherer Typ 'LPSTR'
[Warnung] JwaWinType.pas(327): Unsicherer Typ 'LPSTR'
[Warnung] JwaWinType.pas(329): Unsicherer Typ 'LPSTR'
[Warnung] JwaWinType.pas(331): Unsicherer Typ 'LPCSTR'
[Warnung] JwaWinType.pas(333): Unsicherer Typ 'LPCSTR'
[Warnung] JwaWinType.pas(243): Unsicherer Typ 'LPSTR'
[Warnung] JwaWinType.pas(245): Unsicherer Typ 'LPCSTR'
[Warnung] JwaWinType.pas(247): Unsicherer Typ 'LPCWSTR'
[Warnung] JwaWinType.pas(249): Unsicherer Typ 'LPWSTR'
[Warnung] JwaWinType.pas(252): Unsicherer Typ 'LPWSTR'
[Warnung] JwaWinType.pas(254): Unsicherer Typ 'LPSTR'
[Warnung] JwaWinType.pas(256): Unsicherer Typ 'PWCHAR'
[Warnung] JwaWinType.pas(258): Unsicherer Typ 'PTSTR'
[Warnung] JwaWinType.pas(259): Unsicherer Typ 'PAnsiChar'
[Warnung] JwaWinType.pas(260): Unsicherer Typ 'PWideChar'
[Warnung] JwaWinType.pas(261): Unsicherer Typ 'Pointer'
[Warnung] JwaWinType.pas(728): Unsicherer Typ 'PAnsiChar'
[Warnung] JwaWinType.pas(751): Unsicherer Typ 'PAnsiChar'

Übrigens: Die Kompilation mit den aktivierten Warnungen zwingt mein Delphi7 in die Knie. Nach einer Weile geht irgendwie nichts mehr (oder sehr langsam).

Es gibt weiterhin Stellen, bei denen gleichwertige Records (LARGE_INTEGER <-> FILETIME) ineinander gecastet werden. Das erzeugt jedoch auch eine Warnung, obwohl es semantisch korrekt ist. Man könnte natürlich auch die einzelnen Recordmitglieder zueinander zuweisen. Das führt jedoch zu mehr Code und eine längere Ausführungsdauer. Bei einer Lib weiß man nie, wofür die Funktion genutzt wird und wie oft sie ausgeführt wird.
Wenn ich nun für diese Warnungen in {$WARNINGS OFF} und {$WARNINGS ON} einschließe und Warnungen allgemein ausschalten, dann bekomme ich trotzdem Warnungen. Um alle Warnungen auszuschalten müsste man sich etwas überlegen oder alle WARNINGS ON entfernen. Das ist wie das Prinzip von Konstanten. Man schaltet an einer Stelle und überall, wo sie vorkommen, gibt es dieselbe Änderung.


DCU-Dateien:
Ich erlebe das mit der JEDI API immer erneut. Es kennt sich kaum jemand mit dem Prinzip aus. Die Leute fügen einfach den Pfad zur PAS-Datei in ihr Projekt ein und gut ist. Und dann bekomme ich Meldungen, dass ihre Projekte ewig zum Kompilieren brauchen und tausend Warnungen ausgeben. Es mag sein, dass für normale Delphianwender, das Warnsystem gut genug ist. Aber für die Verwaltung von größeren Bibliotheken ist es mangelhaft. Das war der Grund warum ich einfach ein {$WARNINGS OFF} eingesetzt habe. Alle Warnungen von JEDI API sind schlichtweg falsch.
Weitherhin muss bei einer Änderung des Quelltextes, die DCU erneut erzeugt werden. Bei JEDI API&WSCL können solche Änderungen schonmal täglich vorkommen. Zudem werden Änderungen über das SVN verteilt, was bedeutet, dass jeder zu beliebigen Zeitpunkten Updates holen kann.
Ich empfehle immer, dass die Leute, welche JwaWindows verwenden, diese als DCU Datei einbinden sollen, da die Kompilationszeit doch erheblich ist. Das Prinzip dahinter muss ich jedoch immer und immer wieder erklären, trotz Tutorials und Anleitungen. Wer sich damit auskennt ist natürlich gut bedient, aber die JEDI API&WSCL soll auch für Anfänger funktionieren. Und das Ziel ist es daher den Spagat hinzubekommen, es allen Recht machen zu können.

Summa summarum:
Bei der JEDI API&WSCL habt ihr also Glück. Es gibt schlichtweg keine Warnungen, die von Relevanz wären. Wir gehen sogar darüber hinaus und nutzen externe Quelltextanalysetools (z.B. PascalAnalyzer), um Probleme zu finden. Aber leider ist dies ein hoher Aufwand und große Hilfe dafür gibt es so gut wie garnicht in der Delphigemeinschaft. Aber deshalb gebe ich nicht auf und empfange natürlich jedes Angebot mit offenen Armen.

[Lasse2002]

Zitat von Dezipaitor:

Bei der JEDI API käme so ein besseres Warnungssystem wirklich gut an, da hier Warnungen ausgegeben werden, die nicht korrekt sind.

Das gibt es schon längst, aber ob es in Delphi 7 geht, weiß ich nicht. Ich hab es gerade in Delphi 2007 getestet:

Delphi-Quellcode:

{$WARN UNSAFE_TYPE OFF}
{$WARN UNSAFE_CODE OFF}

// JEDI Code mit ganz vielen UNSAFE_... Warnungen

{$WARN UNSAFE_TYPE DEFAULT}
{$WARN UNSAFE_CODE DEFAULT}

Oder für Text nach dem offiziellen Ende von Units:

Delphi-Quellcode:

{$WARN GARBAGE OFF}
end.

afsfaf
{$WARN GARBAGE DEFAULT}

[Dezipaitor]

Ich habe mir grad Mabuses Post durchgelesen. Da stehen die drin. Diese gibt es leider erst ab Delphi7, aber ich werde sie trotzdem mit entsprechenden IFDEFS einfügen.

[SubData]

Zitat von Dezipaitor:

Delphi-Quellcode:

var
  _AddSecurityPackageW: Pointer;

function AddSecurityPackageW;
begin
  GetProcedureAddress(_AddSecurityPackageW, secur32, 'AddSecurityPackageW');
  asm
        MOV     ESP, EBP
        POP     EBP
        JMP     [_AddSecurityPackageW]
  end;
end;

Warum? Ist doch korrekt.
Wenn der Aufruf von GetProcedureAddress fehlschlagen würde, hättest du ein undefiniertes Ergebnis.

[MaBuSE]

Zitat von Dezipaitor:

Ich habe mir grad Mabuses Post durchgelesen. Da stehen die drin. Diese gibt es leider erst ab Delphi7, aber ich werde sie trotzdem mit entsprechenden IFDEFS einfügen.

Da die JEDI Ritter in der Regel *.inc Dateien einbinden, brauchst du die {$warn ... OFF} nur genau an einer (!!!) Stelle eintragen und hast für den JEDI Code Ruhe

-> jedi.inc

[Dezipaitor]

GetProcedureAddress wirft eine Exception im Fehlerfall. Und selbst wenn nicht, dann ist _AddSecurityPackageW = nil und dann würde JMP _AddSecurityPackageW eine Exception werfen. Es gibt kein normalen Ausgang im Fehlerfall.

[MaBuSE]

Zitat von Dezipaitor:

GetProcedureAddress wirft eine Exception im Fehlerfall. Und selbst wenn nicht, dann ist _AddSecurityPackageW = nil und dann würde JMP _AddSecurityPackageW eine Exception werfen. Es gibt kein normalen Ausgang im Fehlerfall.

Genau das ist das allgemeine Problem:
Man (Du) geh(s)t davon aus, dass der Pointer immer mit nil vordefiniert ist.
Das mag in der aktuellen Compilerversion so sein, ist aber für alle zukünftigen nicht garantiert.

Aus diesem Grund sollen Variablen (und dazu gehört auch Dein Pointer) initialisiert werden.