Re: Handling von Fehlern, Warnungen und Hints
Zitat:
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. |
Re: Handling von Fehlern, Warnungen und Hints
Na dann, in your face, alzaimar ;-)
Gruß -- |
Re: Handling von Fehlern, Warnungen und Hints
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... |
Re: Handling von Fehlern, Warnungen und Hints
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:
"Rückgabewert der Funktion AddSecurityPackageW könnte undefiniert sein" - Das ist hier falsch.
var
_AddSecurityPackageW: Pointer; function AddSecurityPackageW; begin GetProcedureAddress(_AddSecurityPackageW, secur32, 'AddSecurityPackageW'); asm MOV ESP, EBP POP EBP JMP [_AddSecurityPackageW] end; end; 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:
Ü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. |
Re: Handling von Fehlern, Warnungen und Hints
Zitat:
Delphi-Quellcode:
Oder für Text nach dem offiziellen Ende von Units:
{$WARN UNSAFE_TYPE OFF}
{$WARN UNSAFE_CODE OFF} // JEDI Code mit ganz vielen UNSAFE_... Warnungen {$WARN UNSAFE_TYPE DEFAULT} {$WARN UNSAFE_CODE DEFAULT}
Delphi-Quellcode:
{$WARN GARBAGE OFF}
end. afsfaf {$WARN GARBAGE DEFAULT} |
Re: Handling von Fehlern, Warnungen und Hints
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.
|
Re: Handling von Fehlern, Warnungen und Hints
Zitat:
Wenn der Aufruf von GetProcedureAddress fehlschlagen würde, hättest du ein undefiniertes Ergebnis. |
Re: Handling von Fehlern, Warnungen und Hints
Zitat:
-> jedi.inc :thumb: |
Re: Handling von Fehlern, Warnungen und Hints
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.
|
Re: Handling von Fehlern, Warnungen und Hints
Zitat:
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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 16:36 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz