Handling von Fehlern, Warnungen und Hints

[Hansa]

Hinweis: Dieser Thread ist eine Abspaltung von diesem hier. Auslöser dieser Diskussion:

Zitat:

Zitat von Dezipaitor

1. Warum sind die compiler direktiven WARNINGS und HINTS global? Sobald eine Unit diese auf OFF setzt, werden andere Units davon auch betroffen.

2. Warum gibt es kein {$IFOPT WARNINGS ON}, {$IFOPT HINTS ON}

3. Warum kann man keine bestimmte Warnungen im Quelltext ausschalten. z.B. die Warnung: "Code behind "end." is ignored...". Warum ist das eigentlich kein HINT stattdessen?

Okay- man sollte vllt für 2. und 3. eher fragen: Wird es soetwas geben...???

--Hier gehts weiter:

Zitat:

Zitat von Dezipaitor

...3. Warum kann man keine bestimmte Warnungen im Quelltext ausschalten. z.B. die Warnung: "Code behind "end." is ignored...". Warum ist das eigentlich kein HINT stattdessen?..

Das könnte tatsächlich besser lediglich ein Hint sein, aber nur das und ähnliches. Aber in der Richtung tut sich auch was. Allerdings umgekehrt rum, als der Fragesteller gerne hätte. Wie die Frage schon indirekt aussagt : Warnings etc. werden lieber unterdrückt. Jetzt wird sogar verlangt, diese komplett unsichtbar zu machen. Borland geht nun zurecht den umgekehrten Weg : die Warnungen können in Zukunft sogar als Error abgehandelt werden. D.h. Programm compiliert nicht mehr zu Ende. Ist das Projekt nun in dieser Richtung eingestellt, dann wirds schwieriger, die Warnungen einfach zu ignorieren und später dann über Delphi zu schimpfen, weils mittlerweile wegen eigenen Uralt-Fehlern lichterloh brennt.

[edit=Phoenix]Thread separiert. Keine Diskussionen im OT bitte. Mfg, Phoenix[/edit]
[edit=Phoenix]Aufhänger der Diskussion eingefügt. Mfg, Phoenix[/edit]

[mkinzler]

Imho sind Warnungen oder Hinweise keine Fehler.

[toms]

Zitat:

Zitat von mkinzler

Imho sind Warnungen oder Hinweise keine Fehler.

Ein Hinweis könnte jedoch auf einen möglichen Fehler hinweisen.

z.B Warnung D2009:

Zitat:

W1058 Implicit string cast with potential data loss from 'string' to 'AnsiString'

[SubData]

Man kann doch aber bestimmte Warnungen für bestimmte Quellcode Abschnitte deaktivieren ...
Sowas geht zumindest in Delphi 7.

Komplett alle Warnungen und Hinweise abzuschalten halte ich für sehr gefährlich.

[mkinzler]

Nein Warnungen sollten natürlich genau betrachtet werden und geprüft werden, ob ein Eingriff nötig ist. Aber Warnungen zu Fehlern zu machen, nur um den Programmierer zu zwingen, die Stelle noch mal genauer anzusehen, finde ich ist der falsche Weg.

[SubData]

Das bedeutet, dass bei Delphi 2009 eine Warnung dazu führt, dass der Compiler anhält?

[toms]

Zitat:

Zitat von SubData

Das bedeutet, dass bei Delphi 2009 eine Warnung dazu führt, dass der Compiler anhält?

Nein.

[Phoenix]

Wenn Du es einschaltest ja.

Diese Option wurde anscheinend sehr oft von den Usern nachgefragt. (u.a. von mir auch mehrfach bei Nick ;-) ). Ich liefere z.B. auch keinen Code aus, der auch nur einen Hinweis enthält.

@mkinzler: Wenn viele andere Leute eben auch Qualitätscode abliefern wollen und dieses Feature nachfragen ist der Einbau denke ich nicht der falsche Weg ;-)

[mkinzler]

Es spricht nichts dagegen, dies als Switch anzubieten, aber als Standard wäre es nicht gut

[SubData]

Solange es aktivierbar / deaktivierbar ist finde ich die Option völlig in Ordnung.

[Phoenix]

Ist es ja. Und die Standard-Einstellungen ist ja auch der bisherige Stand. Nur kann man eben - so man denn will - einschalten dass Warnungen als Fehler behandelt werden. Ich habs an (schon seitdem Andreas das in den DDevExtensions drin hat) und bin happy damit :)

[alzaimar]

Wer Hinweise und Warnungen grundsätzlich ignoriert, wird nie ordendliche und robuste Software erstellen. Natürlich kann man einige Warnungen/Hinweise ignorieren, wenn man weiss, was man tut.

@mkinzler: Das, was in Delphi eine Warnung ist ("Funktion liefert u.U. kein Resultat", "Variable ist nicht initialisiert") ist in C# beispielsweise ein Fehler. Und das ist es ja auch! Zwar kein syntaktischer Fehler, aber dafür ein sematischer. Oder kennt einer von Euch ein Einsatzgebiet, in dem so ein Konstrukt Sinn ergibt?

Ich habe bei mir alle Warnungen eingeschaltet, ausgenommen die Warnungen für 'Unsicheren Code/Typ/Typumwandlung'. Ich habe es mir zur Angewohnheit gemacht, alle Warnungen und Hinweise in Ordnung zu bringen und empfinde Fremdmodule, die mir die Warnungen nur so um die Ohren hauen, als Laiengeschmier. Meistens (oder eigentlich immer) sind sie es nach genauerem Hinsehen dann auch.

[Dezipaitor]

Boah, ich glaube meine Fragen wurden völlig falsch interpretiert.

Ich habe nichts gegen das Warnungssystem! Bei JWSCL habe ich sogar alle "echten" Warnungen korrigiert, so dass nur noch "Text hinter dem end. wird vom Compiler ignoriert" existiert. Der Text, der da genannt wird ist übrigens ein {$ENDIF}.

Warum Warnungen ausschalten im Quelltext? Für manche Warnungen oder Hinweise (deprecated, plattformabhängig usw), wäre das wirklich fabelhaft, weil sie eigentlich nur stören und keinen Sinn für die Situation haben.

Worauf ich mich beziehe ist das hier :
http://members.aye.net/~bstowers/del...ndWarnings.htm (bitte zu Bug #148; scrollen)

Zitat:

There are bugs in Delphi 2.0 and Delphi 3.0 that relate to the "localness" of the $HINTS and $WARNINGS directives. These directives do not have the same scope as other local directives like the $ALIGN directive.

PS.
Sollten Warnungen irgendwann fest als Fehler erkannt werden, dann kann ich schon jetzt vorhersagen, dass es einige Delphientwickler weniger geben wird (und ich bin keiner davon). Aber selbst C++ ist da 100% flexibler. Und so hätte ichs auch gerne für die Warnungen.

[calculon]

Zitat:

Zitat von Phoenix

[..] Ich liefere z.B. auch keinen Code aus, der auch nur einen Hinweis enthält. [..]

Auch nicht mit diesem :gruebel: ?

Zitat:

[Warnung] uMain.pas(7): Unit 'FileCtrl' ist plattformspezifisch

Gruß
--

[Phoenix]

Nein. Aber meine Anwendungen enthalten auch die Unit FileCtrl nicht ;-)

[calculon]

Na dann, RESCHPEKT! Ich benutze sie des öfteren und die Warnung hatte mich anfangs irritiert. Inzwischen ignoriere ich sie einfach ;-)

Gruß
--

[alzaimar]

Zitat:

Zitat von Dezipaitor

Warum Warnungen ausschalten im Quelltext? Für manche Warnungen oder Hinweise (deprecated,...

Nun ja. Mein Code soll ein paar Jahre halten und da ist es schon sinnvoll, auf soetwas aufmerksam gemacht zu werden. Daher kann man sie ja individuell ein/ausschalten.

Zitat:

Zitat von Dezipaitor

Worauf ich mich beziehe ist das hier

Was für ein dämlich konstruierter 'Bug'. Wer soetwas kodiert, gehört geteert und gefedert. Soll er doch gleich C oder ASM nehmen. Buäh.

Zitat:

Zitat von Dezipaitor

Sollten Warnungen irgendwann fest als Fehler erkannt werden, dann kann ich schon jetzt vorhersagen, dass es einige Delphientwickler weniger geben wird

Die (Entwickler)-Welt wird sich nach deiner Auffassung in zwei Lager spalten:
1. Die "Wir-entwickeln-sicheren-Code"-Fraktion.
Bevorzugte Sprachen: z.B. C#, Java oder auch Delphi (wenn Delphi so lange überlebt)

2. Die "Was-soll-der-Mist-ich-bin-der-Herr-über-meinen-Code"-Fraktion
Ent(fr/w)ickelt wird in C, C++ und anderen Verdächtigen und die sind dann weiterhin für die vielen Bufferoverflows und schlechten Programme verantwortlich.

Natürlich muss man die Warnungen und Hinweise genau studieren. Ich für meinen Teil begrüße die Möglichkeit, sich Warnungen als Fehler anzeigen lassen zu können.

Zitat:

Zitat von calculon

Na dann, RESCHPEKT! Ich benutze sie des öfteren und die Warnung hatte mich anfangs irritiert. Inzwischen ignoriere ich sie einfach ;-)

[ ] Du entwickelst robusten Code.

[divBy0]

Zitat:

[Warnung] uMain.pas(7): Unit 'FileCtrl' ist plattformspezifisch

Das ist bei mir eigentlich immer die einzigste Warnung, die bestehen bleibt. Kann man denn eine Unit/Programm als reine Win32-Plattform kennzeichnen oder wie "umgeht" ihr die Warnung?

Alternativen?

[calculon]

Zitat:

Zitat von divBy0

Zitat:

[Warnung] uMain.pas(7): Unit 'FileCtrl' ist plattformspezifisch

Das ist bei mir eigentlich immer die einzigste Warnung, die bestehen bleibt. Kann man denn eine Unit/Programm als reine Win32-Plattform kennzeichnen oder wie "umgeht" ihr die Warnung?

Alternativen?

Zitat:

Zitat von Delphi Hilfe

Die gesamte Unit ist (mit der Hinweisdirektive platform) als eine gekennzeichnet, die Inhalte enthält, die nicht auf allen Plattformen verfügbar sind. Wenn Sie plattformübergreifende Anwendungen erstellen, kann dies zu Problemen führen. Beispielsweise wird platform bei Units mit Objekten angegeben, die in OleAuto definiert sind.

Mit der Compiler-Direktive $WARN UNIT_PLATFORM ON/OFF können alle derartigen Warnungen für Units aktiviert oder deaktiviert werden.

Zitat:

Zitat von alzaimar

Zitat:

Zitat von calculon

Na dann, RESCHPEKT! Ich benutze sie des öfteren und die Warnung hatte mich anfangs irritiert. Inzwischen ignoriere ich sie einfach ;-)

[ ] Du entwickelst robusten Code.

[X] People like me just don't give a shit ;-)

Gruß
--

[alzaimar]

Zitat:

Zitat von calculon

Zitat:

Zitat von alzaimar

[ ] Du entwickelst robusten Code.

[X] People like me just don't give a shit ;-)

[X] So then halts doch your Mowl when Earwaxene sish underholden. :mrgreen:

Nee, nee. Is schon ok. Jedem das Seine...

[Hansa]

Zitat:

Zitat von Dezipaitor

Sollten Warnungen irgendwann fest als Fehler erkannt werden, dann kann ich schon jetzt vorhersagen, dass es einige Delphientwickler weniger geben wird...

Warum denn diese Schwarzmalerei ? So blöd sind die nicht. Hoffentlich. :mrgreen: Habe mir überlegt, dass auch der "Text hinter end...." einer Warung würdig ist. WIe schnell haben einige den . mit ; verwechselt ? Falsche C+P ? :gruebel: Und dann wundern sie sich, dass die zuletzt geschriebene Prozedur fürs Verrecken nicht ausgeführt wird. :shock:

[alzaimar]

Zitat:

Zitat von Hansa

Warum denn diese Schwarzmalerei ? So blöd sind die nicht. Hoffentlich. :mrgreen:

Entweder sie sind so blöd, oder Delphi ist noch schneller tot.

Wieso sollte das hier nur einer Warnung würdig sein:

Delphi-Quellcode:

Function TMyClass.FooBar : TSometing;
Begin
  If FSomeField > 123 Then
    Result := SomethingElse
End;

oder z.B.:

Delphi-Quellcode:

Procedure TMyClass.BarFoo;
Var
  iMyVariable : Integer;

Begin
  If iMyVariable>123 Then
    DoSomething;
...

Das sind F-e-h-l-e-r. Ganz einfach.

Ich sach ja: Differenzieren muss man schon. Pauschal die Warnungen und Hinweise ignorieren führt zu interessanten Ergebnissen (a.k.a 'AV')

[mkinzler]

Es sagt auch niemand, dass man Warnungen pauschal ignorieren soll

[Dezipaitor]

Es geht eigentlich darum, warum WARNINGS OFF nicht lokal sondern global, Warnungen ausschalten kann.
Wenn man eine fremde Unit verwendet, die soviele Warnungen produziert, dann kann man diese nicht unterdrücken, ohne alle Warnungen (auch seine eigenen) zu ignorieren.

[MaBuSE]

Zitat:

Zitat von SubData

Man kann doch aber bestimmte Warnungen für bestimmte Quellcode Abschnitte deaktivieren ...
Sowas geht zumindest in Delphi 7.

Komplett alle Warnungen und Hinweise abzuschalten halte ich für sehr gefährlich.

Ich gebe SubData Recht ;-)

Hab mal vor längerer Zeit ein Tutorial dazu geschrieben:
Tutorial: Warnungen und Hinweise vom Delphi Compiler

Schade, dass das so wenige lesen :(

[Hansa]

Zitat:

Zitat von Dezipaitor

Es geht eigentlich darum, warum WARNINGS OFF nicht lokal sondern global, Warnungen ausschalten kann..

Wieso global ? :gruebel: Die Delphi-Hilfe meint dazu das :

Delphi-Quellcode:

Durch Einfügen von Quelltext zwischen {$WARNINGS OFF} und {$WARNINGS ON} können Sie die Generierung von überflüssigen Warnmeldungen deaktivieren.

Oder soll Delphi hellsehen, wie es in deinem Quelltext aussieht ?

[Dezipaitor]

Zitat:

Zitat von SubData

Man kann doch aber bestimmte Warnungen für bestimmte Quellcode Abschnitte deaktivieren ...
Sowas geht zumindest in Delphi 7.

Leider ist es nicht konsequent.

{$WARNINGS OFF} ist GLOBAL. <-- Das ist es, was ich denke, dass es abgeschafft werden sollte und durch eine lokale Direktive ersetzt.
Es gibt {$WARN xx OFF} für bestimmte Warnungen, die sind lokal.

[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;

[calculon]

Zitat:

Zitat von MaBuSE

Zitat:

Zitat von SubData

Man kann doch aber bestimmte Warnungen für bestimmte Quellcode Abschnitte deaktivieren ...
Sowas geht zumindest in Delphi 7.

Komplett alle Warnungen und Hinweise abzuschalten halte ich für sehr gefährlich.

Ich gebe SubData Recht ;-)

Hab mal vor längerer Zeit ein Tutorial dazu geschrieben:
Tutorial: Warnungen und Hinweise vom Delphi Compiler

Schade, dass das so wenige lesen :(

Sehr schön

Zitat:

{$WARN UNIT_PLATFORM OFF}
Warnung: Unit '<Element>' ist plattformspezifisch
Die gesamte Unit ist (mit der Hinweisdirektive platform) als eine gekennzeichnet, die Inhalte enthält, die nicht auf allen Plattformen verfügbar sind. Wenn Du plattformübergreifende Anwendungen erstellst, kann dies zu Problemen führen. Beispielsweise wird platform bei Units mit Objekten angegeben, die in OleAuto definiert sind.
Mit Platform ist Windows / Linux gemeint. Meist bedeutet das, das man eine Unit verwendet, die nur unter Windows verfügbar ist.

Also kann man doch diese Meldung heutzutage wo Kylix doch tot ist und man damit sowieso nicht mehr für Linux entwickeln sollte, diese Meldungen getrost ignorieren und trotzdem "robusten" Code produzieren, oder?

Gruß
--

[MaBuSE]

Zitat:

Zitat von calculon

Zitat:

Zitat von MaBuSE

...
Schade, dass das so wenige lesen :(

Sehr schön

Zitat:

{$WARN UNIT_PLATFORM OFF}
Warnung: Unit '<Element>' ist plattformspezifisch
...
Mit Platform ist Windows / Linux gemeint. Meist bedeutet das, das man eine Unit verwendet, die nur unter Windows verfügbar ist.

Also kann man doch diese Meldung heutzutage wo Kylix doch tot ist und man damit sowieso nicht mehr für Linux entwickeln sollte, diese Meldungen getrost ignorieren und trotzdem "robusten" Code produzieren, oder?

Genau dafür ist das gedacht !!!
:-)

Kann man sogar in den "Projekt -> Optionen -> Compiler-Meldungen" einstellen

[Dezipaitor]

Zitat:

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:

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:

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:

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

:thumb:

[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:

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.