Handling von Fehlern, Warnungen und Hints

[Dezipaitor]

Globale Variablen werden schon immer mit 0 initialisiert.

Das ist ein dokumentiertes Verhalten und wird sicher nicht in Zukunft geändert.

[SubData]

"Result" ist aber keine globale Variable und um die geht es hier ;-)

[MaBuSE]

Zitat:

Zitat von Dezipaitor

Globale Variablen werden schon immer mit 0 initialisiert.

Stimmt, aber es wird trotzdem eine Warnung ausgegeben.

in der Delphi Hilfe steht:

Wenn Sie eine globale Variable nicht explizit initialisieren, wird sie vom Compiler zunächst auf 0 gesetzt. Lokale Variablen können bei der Deklaration nicht initialisiert werden. Sie sind nicht definiert, solange ihnen kein Wert zugewiesen wird.

bei Funktionen gilt aber folgendes:

in der Delphi Hilfe steht:

Wenn die Ausführung einer Funktion beendet wird, bevor Result oder dem Funktionsnamen ein Wert zugewiesen wurde, ist der Rückgabewert der Funktion nicht definiert.

Nach dieser Definition ist die Warnung OK.

Das der Rückgabewert auch nur eine Variable ist, das steht auf einem anderen Blatt. ;-)

[Dezipaitor]

Zitat:

"Result" ist aber keine globale Variable und um die geht es hier

Nein, es ging nicht um Result, sondern um den Pointer. Zumindest habe ich das so verstanden:

Zitat:

Man (Du) geh(s)t davon aus, dass der Pointer immer mit nil vordefiniert ist.

Also geht es um "_AddSecurityPackageW: Pointer;". Und dieser ist immer mit nil vorbelegt.


Result steckt in dem AX Register, welches von der Funktion, angesprungen durch JMP, gesetzt wird. Somit ist der Rückgabewert definiert. Aber das kann Delphi natürlich nicht erkennen. Daher ist die Warnung semantisch falsch.

[Chemiker]

Hallo,

ich habe zwar in meinen normalen Programmen auch keine Warnungen, aber wenn jemand eine Idee hat wie man die Fehler abstellen kann die unter Struktur angezeigt werden.

In einigen Programmen arbeite ich mit OLE-Automation späte Bindung.

z.B. :

Delphi-Quellcode:

OleInstanc.ActiveWorkbook.Close (saveChanges:=True, FileName:=strName);

Dann werden unter Struktur 2 Fehler angezeigt:

Nicht deklarierter Bezeichner ‚saveChanges’ in Zeile 3040
Nicht deklarierter Bezeichner ‚FileName’ in Zeile 3040

Die kann weder mit HINT noch mit WARNINGS abstellen.


Bis bald Chemiker

[Dezipaitor]

Ich glaube, wenn du ein neues Thema aufmachst mit deine Frage, dann können dir sicher mehr Leute helfen.

[Chemiker]

Hallo Dezipaitor,

Zitat:

Zitat von Dezipaitor

Ich glaube, wenn du ein neues Thema aufmachst mit deine Frage, dann können dir sicher mehr Leute helfen.

Das war jetzt nicht eine konkrete Frage. Sondern der Beitrag war nur als Hinweis, weil die Meinung vertreten wird, dass man alle Warnungen und Fehler ausstellen kann.

Bis bald Chemiker

[Dezipaitor]

Ah ok. Da hab ich die lange Tradition von Missverständnissen nur vortgeführt :mrgreen:

[MaBuSE]

Zitat:

Zitat von Chemiker

Das war jetzt nicht eine konkrete Frage. Sondern der Beitrag war nur als Hinweis, weil die Meinung vertreten wird, dass man alle Warnungen und Fehler ausstellen kann.

Was Du beschreibst ist aber was völlig anderes. Wir reden hier von den "echten" Compiler Warnungen und Hinweisen. Also das was der Compiler ausgibt. Du spricht von ErrorInsight, also dem was die IDE beim Parsen des Codes für Anstößig hällt.

Wenn der Compiler einen Fehler ausgibt, dann kann das Projekt nicht erstellt werden.

Denn ErrorInsight einen Fehler ausgibt und der Compiler trotzdem kompilieren kann, dann liegt ErrorInsight falsch. :stupid:
Das wäre dann einen Eintrag in dem BugTracking Tool von CodeGear wert. ( http://qc.codegear.com )

und hat mit den hier beschriebenen Problem eigentlich nichts zu tun.

ps: Das soll übrigens nicht als Beschwerde, sondern als Erklärung verstanden werden. Ich freue mich über jeden konstruktiven Beitrag im Forum, und dazu zählt er auf jeden Fall.

[HeikoAdams]

Zitat:

Zitat von Dezipaitor

"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.

Das bedeutet im Umkehrschluss, das Du vom Compiler erwartest, das er bei Funktionen nicht nur nach "Result :=" oder "Funktionsname :=" suchen soll, sondern auch noch eventuell vorhandenen ASM-Code parsen soll, ob eventuell dort das entsprechende Register bestückt wird?

Sorry, aber wer zu faul ist, "Result :=" oder "Funktionsname :=" in seine Funktion zu schreiben, der hat nichts anderes als die entsprechende Warnung verdient. :evil:

Ebenso gefährlich finde ich, das es überhaupt die Möglichkeit gibt, Warnungen für ein gesamtes Projekt zu deaktivieren. Nur weil die Warnungen im Moment unbegründet sind, darf man als verantwortungsvoller Entwickler nicht davon ausgehen, dass das auch zukünftig der Fall ist!

Zitat:

Zitat von Dezipaitor

Globale Variablen werden schon immer mit 0 initialisiert.
Das ist ein dokumentiertes Verhalten und wird sicher nicht in Zukunft geändert.

Dazu sage ich nur: Verlass Dich auf andere und Du bist verlassen.
Wer sagt Dir, das es nicht zukünftig einen (ge)wichtigen Grund für CodeGear gibt, das beschriebene Verhalten doch zu verändern?

Mein Informatik-Lehrer hat uns förmlich eingeprügelt, anstellen von

Delphi-Quellcode:

if a <= b then

nur

Delphi-Quellcode:

if (a <= b) then

zu schreiben, da man nie sicher sein kann, das sich das Verhalten des Compilers in diesem Punkt nicht doch irgendwann ändert.
Sein Credo war damals: Im Leben ist nur eins sicher: Der Tod.

[alzaimar]

*schnipps* *meld*

Ah... Wieso nicht einfach bei Hack-Units die Warnungen ausschalten? Solche Units basieren eh auf dem Compiler und sind weder Plattform- noch Compilerunabhängig, weil auf bestimmte Registerkonventionen, Stackaufbau usw. gebaut wird.
Man umgeht in so einem Hack sowieso (aus Performancegründen oder weil es anders einfach nicht geht) das Bestreben einer modernen Programmiersprache, schwere Fehler zu vermeiden und setzt sich bewusst der Gefahr aus, das System zu zerballern.

[HeikoAdams]

Zitat:

Zitat von alzaimar

Man umgeht in so einem Hack sowieso (aus Performancegründen oder weil es anders einfach nicht geht) das Bestreben einer modernen Programmiersprache, schwere Fehler zu vermeiden und setzt sich bewusst der Gefahr aus, das System zu zerballern.

Das wäre für mich eher ein Grund, solche Units soweit möglich zu meiden. Auch wenn man für Software, die das System zerballert, nicht haftbar gemacht werden kann, der Ruf ist dann schnell ruiniert.

[SubData]

Naja, es gibt einfach Situationen in denen man mit nem "dreckigen Hack" mehrere Stunden umständliche Programmierung sparen kann.

Man muss nur wirklich wissen, was man tut und sollte sich auf keinen Fall auf fremde Hacks verlassen (wenn man sie nicht versteht).

[alzaimar]

Zitat:

Zitat von HeikoAdams

Das wäre für mich eher ein Grund, solche Units soweit möglich zu meiden. Auch wenn man für Software, die das System zerballert, nicht haftbar gemacht werden kann, der Ruf ist dann schnell ruiniert.

Die System.pas müsstest Du dann meiden ;-) ebenso wie diverse low-level und performanceoptimierte Routinen. Was meinst du, wie es hinter den Kulissen von dot.Net aussieht?

[SubData]

Wenn ich da an FastCode denke... Holla ;-)

[HeikoAdams]

Zitat:

Zitat von alzaimar

Die System.pas müsstest Du dann meiden ;-) ebenso wie diverse low-level und performanceoptimierte Routinen. Was meinst du, wie es hinter den Kulissen von dot.Net aussieht?

Ich denke mal, das man Hack-Units, die von CodeGear ausgeliefert werden zumindest soweit getestet sind, das sie keine größeren Schäden anrichten.

Bei Hack-Units, die von privaten Projekten entwickelt und gepflegt werden, würde ich so eine Aussage jedoch nicht sofort und ohne weiteres Unterschreiben.

[SubData]

Es geht ja garnicht darum, dass du fremde Units verwendest, sondern ggf. auch darum, dass du evtl selbst solche Hacks verwendest.

[MaBuSE]

Hallo ich habe mal den Sachverhalt von Dezipaitor in einem kompilierbaren Beispiel verdeutlicht.

Vorgehensweise zum selbst Testen:

• Quelltext der Unit komplett markieren und kopieren (Strg+C)
• Neue Anwendung erstellen einen TButton drauf, ein TMemo drauf.
• Den Button doppelklicken -> Quelltextfenster mit Methoden erscheint.
• Kompletten Quelltext mit Strg+A markieren und durch Strg+V mit dem aus der Zwischenablage ersetzen.
• Kopileren und debuggen.

Dei Kommentare im Code sollten alles erklären.

mfg
MaBuSE

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type
  TForm1 = class(TForm)
    Button1: TButton;
    Memo1: TMemo;
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

// Hier werden die kompletten Funktionen definiert
// Im implementation Teil darf dann die Definition etwas abgekürzt werden
// (Z.B. darf der Rückgabetyp weggelassen werden.)
function TestIt1: Pointer;
function TestIt2: Pointer;
function TestIt3: Pointer;
function TestIt4: Pointer;

implementation

{$R *.dfm}

var
  _TestIt1: Pointer;
  _TestIt2: Pointer;

function TestIt1;
begin
  // Der Variable _TestIt1 wird das Ergebnis zugewiesen, das hat nix mit Result
  // zu tun -> Result ist undefiniert und war bei meinen Tests nicht immer nil!
  _TestIt1 := @Form1;
end;

function TestIt2;
begin
  // Der Variable _TestIt2 wird die Adresse der Funktion TestIt3 zugewiesen,
  // das hat nix mit Result zu tun -> Result ist noch undefiniert.
  _TestIt2 := @TestIt4;

  // Hier wird direkt in die TestIt4 Funktion gesprungen
  // -> also zu dem Result := @Form1 , danach wird nur ein RET duchgeführt.
  // Damit ist in dem EAX-Register zur Rückgabe der Wert @Form1 enthalten
  // und das Result wurde damit implizit gesetzt.
  asm
    JMP     _TestIt2
  end;
end;

// Hier funktioniert es nicht, da der Compiler erkennt, das TestIt4 das
// EAX-Register verändert. Deshalb baut er beim Begin ein Push EBX ein
// Das Result würde nun in EBX gespeichert und beim end; wieder in EAX
// kopiert und der ursprüngliche EBX Wert wieder hergestellt (pop ebx).
// Damit ist das Result wieder undefiniert ;-)
function TestIt3;
begin         // ASM: 53 - push ebx
  TestIt4;    // ASM: E806000000 - call TestIt4
end;          // ASM: 8BC3 - mov eax,ebx
              // ASM: 5B - pop ebx
              // ASM: C3 -ret

function TestIt4;
begin
  Result := @Form1;   // ASM:  B8C80C4600 - mov eax, @Form1
end;                  // ASM: C3 - ret

procedure TForm1.Button1Click(Sender: TObject);
var
  p: Pointer;
begin
  // Anmerkung die p := nil;  Zeilen werden vom Compiler alle wegoptimiert.
  // Sie dienen nur der Übersichtlichkeit ;-)

  p := nil;
  p := TestIt1;  // p ist undefiniert (kann, muß aber nicht nil sein)
  Memo1.Lines.Add('p        = $'+ IntToHex(Integer(p),8));
  Memo1.Lines.Add('_TestIt1 = $'+ IntToHex(Integer(_TestIt1),8));

  p := nil;
  p := TestIt2;  // in p steht das richtige Ergebnis
  Memo1.Lines.Add('p        = $'+ IntToHex(Integer(p),8));
  Memo1.Lines.Add('_TestIt2 = $'+ IntToHex(Integer(_TestIt2),8));

  p := nil;
  p := TestIt3;  // p ist undefiniert (kann, muß aber nicht nil sein)
  Memo1.Lines.Add('p        = $'+ IntToHex(Integer(p),8));

  p := nil;
  p := TestIt4;  // in p steht das richtige Ergebnis
  Memo1.Lines.Add('p        = $'+ IntToHex(Integer(p),8));
end;

end.

[Dezipaitor]

Zitat:

Zitat von HeikoAdams

Zitat:

Zitat von Dezipaitor

"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.

Das bedeutet im Umkehrschluss, das Du vom Compiler erwartest, das er bei Funktionen nicht nur nach "Result :=" oder "Funktionsname :=" suchen soll, sondern auch noch eventuell vorhandenen ASM-Code parsen soll, ob eventuell dort das entsprechende Register bestückt wird?

Nein, natürlich nicht. Aber wenn es sowas wie {$WARN UNDEFINED_RESULT OFF} und {$WARN UNDEFINED_RESULT DEFAULT} gegeben hätte, dann wären nun über 3000 Funktionen, die semantisch korrekt einen Rückgabewert liefern, ohne diese Warnungen. Dadurch würden Warnungen aufgedeckt, die auch stimmen.

Zitat:

Sorry, aber wer zu faul ist, "Result :=" oder "Funktionsname :=" in seine Funktion zu schreiben, der hat nichts anderes als die entsprechende Warnung verdient. :evil:

Ich glaube, du wärst auch zu faul, dies in über 3000 Funktionen einzubauen. Zudem wäre das ein beträchtlicher Anstieg von Code in der Binärdatei. Außerdem ist jeder Aufruf mit Zeitverlust verbunden, da, wenn von Delphi nicht herausgerechnet, ja auch Code ausgeführt wird. Und bei einer Library weiß man nie wie oft die Funktionen aufgerufen werden. Würde ich nur wegen den Warnungen überall, ein Result einfügen, dann würde ich sicherlich eine Menge Mails deshalb bekomme, warum der Code so groß geworden ist (bei vielen Funktionsaufrufen).

Zitat:

Ebenso gefährlich finde ich, das es überhaupt die Möglichkeit gibt, Warnungen für ein gesamtes Projekt zu deaktivieren. Nur weil die Warnungen im Moment unbegründet sind, darf man als verantwortungsvoller Entwickler nicht davon ausgehen, dass das auch zukünftig der Fall ist!

Es ist viel gefährlicher, wenn man von ungültigen Warnungen bomadiert wird und bei einer riesigen Liste die echten Warnungen nicht mehr sieht. Zudem dauert die Erstellung von Projekten mit vielen Warnungen sehr lange. Es mag für den Anwendungsentwickler nicht von belang sein, aber für große Projekte und Libs ist das nicht förderlich.

Zitat:

Zitat:

Zitat von Dezipaitor

Globale Variablen werden schon immer mit 0 initialisiert.
Das ist ein dokumentiertes Verhalten und wird sicher nicht in Zukunft geändert.

Dazu sage ich nur: Verlass Dich auf andere und Du bist verlassen.
Wer sagt Dir, das es nicht zukünftig einen (ge)wichtigen Grund für CodeGear gibt, das beschriebene Verhalten doch zu verändern?

Garantie wird es keine geben. Da es jedoch dokumentiert ist, kann man sich darauf verlassen, dass die Kompatibilität beibehalten und bei einer Änderung frühzeitig bescheid gegeben wird. Wäre das nicht so, würden eine Menge Delphianwendungen von heute auf morgen nicht mehr funktionieren. Das kann ich garantieren. Schließlich wird auch nicht plötzlich die Prozedur Inc geändert, so dass sie dekrementiert.

Zitat:

Mein Informatik-Lehrer hat uns förmlich eingeprügelt, anstellen von

Delphi-Quellcode:

if a <= b then

nur

Delphi-Quellcode:

if (a <= b) then

zu schreiben, da man nie sicher sein kann, das sich das Verhalten des Compilers in diesem Punkt nicht doch irgendwann ändert.
Sein Credo war damals: Im Leben ist nur eins sicher: Man stirb früher oder später.

Klammern zu schreiben ist ja ok. Besonders wenn es größere Bedinungen gibt, ist das ein muss. Aber es ist normal, dass man in der Lehre etwas härter darauf trainiert wird, niemandem und nichts zu vertrauen. Aber wenn man das auf die Wirtschaft übertragen würde, würde es wohl einen Stillstand geben.

Zitat:

Zitat von alzaimar

*schnipps* *meld*
Ah... Wieso nicht einfach bei Hack-Units die Warnungen ausschalten? Solche Units basieren eh auf dem Compiler und sind weder Plattform- noch Compilerunabhängig, weil auf bestimmte Registerkonventionen, Stackaufbau usw. gebaut wird.
Man umgeht in so einem Hack sowieso (aus Performancegründen oder weil es anders einfach nicht geht) das Bestreben einer modernen Programmiersprache, schwere Fehler zu vermeiden und setzt sich bewusst der Gefahr aus, das System zu zerballern.

Man kann es nicht für diese Units allein ausschalten, da WARNINGS OFF global, also für alle Units gilt. Wenn der compiler einmal an diese Direktive angekommen ist, dann gibt es danach für eigene Units keine Warnungen mehr.

[MaBuSE]

Zitat:

Zitat von Dezipaitor

Nein, natürlich nicht. Aber wenn es sowas wie {$WARN UNDEFINED_RESULT OFF} und {$WARN UNDEFINED_RESULT DEFAULT} gegeben hätte, dann wären nun über 3000 Funktionen, die semantisch korrekt einen Rückgabewert liefern, ohne diese Warnungen. Dadurch würden Warnungen aufgedeckt, die auch stimmen.
...

Zitat:

Zitat von alzaimar

... Wieso nicht einfach bei Hack-Units die Warnungen ausschalten? ...

Man kann es nicht für diese Units allein ausschalten, da WARNINGS OFF global, also für alle Units gilt. Wenn der compiler einmal an diese Direktive angekommen ist, dann gibt es danach für eigene Units keine Warnungen mehr.

Das ist auch der Grund warum ich mir in Fragen an CodeGearThread gewünscht habe, dass man einzelne Warnungen über die Nummer und nicht nur über die Gruppe ausschalten kann.

Delphi-Quellcode:

{$WARN W1035 OFF} // Warnung "W1035 Rückgabewert der Funktion <name> könnte undefiniert sein" unterdrücken.

[SubData]

Pack an das Ende der Unit ein WARNINGS ON, dann dürfte es wieder stimmen.

Zitat:

Zitat von MaBuSE

Das ist auch der Grund warum ich mir in Fragen an CodeGearThread gewünscht habe, dass man einzelne Warnungen über die Nummer und nicht nur über die Gruppe ausschalten kann.

Delphi-Quellcode:

{$WARN W1035 OFF} // Warnung "W1035 Rückgabewert der Funktion <name> könnte undefiniert sein" unterdrücken.

SEHR schöne Idee! :)

[MaBuSE]

Zitat:

Zitat von SubData

Pack an das Ende der Unit ein WARNINGS ON, dann dürfte es wieder stimmen.

Es sei denn ich möchte aus irgendwelchen Gründen alle Warnungen des Compilers mit der DCC32 Compileroption ausschalten.
Das würde damit rückgängig gemacht werden :-(

[nahpets]

Hallo,

meine Devise:

Wenn Programme rausgehen an den Kunden, haben sie keine Hinweise und Warnungen mehr (ausser Plattform, da gibt's halt nur Windows).

Bei Programmen für den eigenen Bedarf bleiben Hinweise und Warnungen nur dann über, wenn ich geprüft habe und ruhigen Gewissens entscheiden kann, für diesen Job ist das okay, das sind dann aber in der Regel nur irgendwelche Tools und Helferlein für den persönlichen Bedarf oder Spielereien für zu Hause.

@MaBuSE, was machst Du denn da in Deinem Beispiel? Okay, ich schreibe in der Regel nur kaufmännische Software, da brauch ich sowas nicht und habe keine entsprechenden Probleme :wink:

Stephan

[alzaimar]

Ich schalte in den Hack-Units am Anfang und nach der Uses-Klausel die Warnungen AUS und am Ende wieder EIN. Das funktioniert.

Das hier gepostete Beispiel ist mir zu konstruiert. Wer solche Konstrukte verwendet, darf die Warnungen getrost ignorieren, ihm ist eh nicht mehr zu helfen.

[Hansa]

Zitat:

Zitat von alzaimar

Ich schalte in den Hack-Units...darf die Warnungen getrost ignorieren, ihm ist eh nicht mehr zu helfen.

:lol: :wall: In den Hack-Units würde es mich eher stören, keine Warnungen zu sehen. :mrgreen: Ich werde jeden Tag mehrmals gewarnt, dass es noch ein FILE OF gibt. Das ist mir vorerst egal, aber wenn ein Dritter mit einem Programm arbeiten muss, dann stelle ich sicher, dass keine Eventualitäten ausgeliefert werden. Das bedeutet in letzter Konsequenz dann eben, die Warnungen als Error zu interpretieren und fertig. Das kann nicht nach dem Motto laufen "es compiliert, wir können ausliefern". 8)

[nahpets]

Zitat:

Zitat von Hansa

Das kann nicht nach dem Motto laufen "es compiliert, wir können ausliefern". 8)

Exakt so sehe ich das auch. Alles Andere halte ich für inakzeptabel.
Vermeintlich fehlerfreie Software gibt es genug und damit ärgern wir uns alle rum.
Da müssen wir es nicht auch so machen.
Es ist zwar schön, wenn man 'nen Servicevertrag hat, aber noch schöner ist es, wenn der nicht in Anspruch genommen werden muss, weil keine Probleme auftreten.

Stephan

[uligerhardt]

Zitat:

Zitat von Dezipaitor

Nein, natürlich nicht. Aber wenn es sowas wie {$WARN UNDEFINED_RESULT OFF} und {$WARN UNDEFINED_RESULT DEFAULT} gegeben hätte, dann wären nun über 3000 Funktionen, die semantisch korrekt einen Rückgabewert liefern, ohne diese Warnungen. Dadurch würden Warnungen aufgedeckt, die auch stimmen.

Es gibt doch {$WARN NO_RETVAL OFF}. Oder steh ich auf dem Schlauch und du meinst was Anderes?

[MaBuSE]

Zitat:

Zitat von nahpets

@MaBuSE, was machst Du denn da in Deinem Beispiel? Okay, ich schreibe in der Regel nur kaufmännische Software, da brauch ich sowas nicht und habe keine entsprechenden Probleme :wink:

Das Beispiel (Beitrag 58) sollte nur zeigen um was es eigentlich bei der Diskussion um den Beitrag 34 in diesem Thread geht.
Dezipaitor hatte ein Stück Sourcecode geposted, über das hier diskutiert wird.

Ich habe nur versucht den Quelltext zu erklären.

Bzw. zu zeigen warum mit dem

Delphi-Quellcode:

 asm      JMP     [_AddSecurityPackageW]  end;

das Result (EAX) gesetzt wird.

[MaBuSE]

Zitat:

Zitat von uligerhardt

Zitat:

Zitat von Dezipaitor

Nein, natürlich nicht. Aber wenn es sowas wie {$WARN UNDEFINED_RESULT OFF} und {$WARN UNDEFINED_RESULT DEFAULT} gegeben hätte, dann wären nun über 3000 Funktionen, die semantisch korrekt einen Rückgabewert liefern, ohne diese Warnungen. Dadurch würden Warnungen aufgedeckt, die auch stimmen.

Es gibt doch {$WARN NO_RETVAL OFF}. Oder steh ich auf dem Schlauch und du meinst was Anderes?

Stimmt, Du hast Recht. :thumb:

Vielleicht hätte ich noch mal mein eigenes Tutorial lesen sollen, :stupid:
dann hätte ich Dezipaitor auch selbst drauf hinweisen können.

[equote="Im Tutorial ( http://www.delphipraxis.net/internal...t.php?t=115445 ) steht:"]{$WARN NO_RETVAL ON}
Warnung: Rückgabewert der Funktion '<Element>' könnte undefiniert sein
Diese Warnung wird angezeigt, wenn dem Rückgabewert einer Funktion nicht in jedem Codepfad ein Wert zugewiesen wurde.
Die Funktion könnte auch ausgeführt werden, ohne dass der Rückgabewert zugewiesen wird.
Die Lösung besteht darin, sicherzustellen, dass der Rückgabewert in jedem möglichen Quelltextpfad zugewiesen wird. [/equote]

Danke

[Dezipaitor]

So langsam wird das Thema unübersichtlich und ich blicke es auch nicht mehr. Jetzt habe ich extra das Tutorial genau angeschaut, aber diese Direktive glatt übersehen. :wall:
Also Freiwillige vor! :duck:

Die JEDI API gibt es seit Delphi 5 (und früher?), als man die Warnungen noch nicht abschalten konnte. Daher steht es nicht drin.

[MaBuSE]

Zitat:

Zitat von Dezipaitor

Die JEDI API gibt es seit Delphi 5 (und früher?), als man die Warnungen noch nicht abschalten konnte. Daher steht es nicht drin.

Du brauchst es doch nur in die JEDI.inc Datei einzubauen.
Diese wird doch in jede Unit eingebunden.
Dort gibt es ja auch die Prüfung welche Delphi Version gerade compiliert.
Du musst also nur eine Zeile Code ändern.

(Ich gehe jetzt von JCL aus, Dein JEDI API kenne ich nicht. ;-) )

[Dezipaitor]

1. Die jedi.inc ist eine gemeinsame genutzte Datei für alle JEDI Projekte.
2. Sowas in die JediAPILib.inc einzubauen, würde die Warnung auch für Funktionen ausschalten, bei der die Warnung gerecht würde (z.b. selbst gebaute, wie GetProcedureAddress).

[MaBuSE]

Zitat:

Zitat von Dezipaitor

1. Die jedi.inc ist eine gemeinsame genutzte Datei für alle JEDI Projekte.
2. Sowas in die JediAPILib.inc einzubauen, würde die Warnung auch für Funktionen ausschalten, bei der die Warnung gerecht würde (z.b. selbst gebaute, wie GetProcedureAddress).

OK jedi.inc scheidet aus

aber immer noch besser in der JediAPILib.inc als das die Benutzer der Lib auf die Idee kommen alle Warnungen komplett auszuschalten.

[Dezipaitor]

Da hast du natürlich auch wieder recht. :wink:

[uligerhardt]

Wie wild sind die einschlägigen Routinen denn im Code verteilt? Wenn sie einigermaßen in Blöcken beieinander stehen, würde es ja reichen, selbige mit {$WARN NO_RETVAL OFF}/{$WARN NO_RETVAL ON} einzurahmen. Funktioniert bei unseren "bösen" Stellen gut.

[Dezipaitor]

Es gibt knapp 6500 solcher Funktionen. Wenn nicht jemand ungeheuer viel Zeit hat, müsste man sowas automatisieren.

[SubData]

Jaein...

Man müsste an den Ecken, wo man sowieso gerade mal rumprogrammiert diese "Fehler" gleich mit korrigieren.
Ok, es ist ein bissi mehr Arbeit dann, aber man baut dann wenigstens so nach und nach Altlasten aus und verbessert den Code...

[uligerhardt]

Zitat:

Zitat von Dezipaitor

Es gibt knapp 6500 solcher Funktionen. Wenn nicht jemand ungeheuer viel Zeit hat, müsste man sowas automatisieren.

So, ich hab mal einen kleinen Test gemacht: jwapi2.2a runtergeladen, ein Test-Konsolenprojekt angelegt, in selbigem JwaSspi ge-used und in den Compileroptionen DYNAMIC_LINK definiert. In der jediapilib.inc das WARNINGS OFF entschärft und kompiliert ==> Bazillionen Warnungen.
Dann hab ich in der JwaSspi und der JwaWinNT jeweils den Block mit diesen ganzen GetProcedureAddress/asm-Konstrukten mit WARN NO_RETVAL OFF/ON geklammert - und voila: keine Warnungen.
Wenn du das Gleiche jetzt in den ~60 pas-Dateien in der jwapi machst, hast du doch das, was du willst?

Uli.

BTW: Die Packages in ...\jwapi2.2a\Packages\bds10 lassen sich nicht out of the box kompilieren. Dem Compiler fehlt ein $DEFINE wegen irgendwas mit ShellApi.

[Dezipaitor]

Zitat:

Zitat von uligerhardt

So, ich hab mal einen kleinen Test gemacht: jwapi2.2a runtergeladen, ein Test-Konsolenprojekt angelegt, in selbigem JwaSspi ge-used und in den Compileroptionen DYNAMIC_LINK definiert. In der jediapilib.inc das WARNINGS OFF entschärft und kompiliert ==> Bazillionen Warnungen.
Dann hab ich in der JwaSspi und der JwaWinNT jeweils den Block mit diesen ganzen GetProcedureAddress/asm-Konstrukten mit WARN NO_RETVAL OFF/ON geklammert - und voila: keine Warnungen.
Wenn du das Gleiche jetzt in den ~60 pas-Dateien in der jwapi machst, hast du doch das, was du willst?

Hast du Lust, dasselbe mit den Trunkdateien zu machen und es zu testen? Wäre nicht schlecht.

Zitat:

BTW: Die Packages in ...\jwapi2.2a\Packages\bds10 lassen sich nicht out of the box kompilieren. Dem Compiler fehlt ein $DEFINE wegen irgendwas mit ShellApi.

Kannst du mir etwas genaueres sagen? Mit Delphi2006 habe ich nur Probleme mit der JWA, so dass ich es nicht mit der IDE testen kann. Mit der dcc32 funkz es jedoch.

[uligerhardt]

Zitat:

Zitat von Dezipaitor

Hast du Lust, dasselbe mit den Trunkdateien zu machen und es zu testen? Wäre nicht schlecht

Kannst du das Ganze mal zippen und hier anhängen oder mir schicken (bin bei gmx in de, ulrich.gerhardt)? Dann schaue ich es mir Montag mal an.
Ich hab's übrigens nochmal mit dem Package JediApi_DynamicRelease probiert und mit geschätzt 10-15 OFF/ON-Blöcken einige Hundert Warnungen beseitigt, bevor ich keine Lust mehr hatte.

Zitat:

Zitat von Dezipaitor

Kannst du mir etwas genaueres sagen? Mit Delphi2006 habe ich nur Probleme mit der JWA, so dass ich es nicht mit der IDE testen kann. Mit der dcc32 funkz es jedoch.

Nochmal Package JediApi_DynamicRelease: In Unit SetupApi läuft er in Zeile 52 auf einen (gewollten) Compilerfehler, weil JWA_INCLUDE_SHELLAPI nicht definiert ist.

BTW im BTW: :mrgreen: Das wäre doch ein Fall für - ich zitiere Mabuse - {$Message Fatal 'Bang. Tot.'} // Fehler, die Compilierung wird abgebrochen.