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.