AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Handling von Fehlern, Warnungen und Hints

Ein Thema von Hansa · begonnen am 17. Sep 2008 · letzter Beitrag vom 19. Sep 2008
Antwort Antwort
Seite 5 von 9   « Erste     345 67     Letzte »    
Dezipaitor

Registriert seit: 14. Apr 2003
Ort: Stuttgart
1.701 Beiträge
 
Delphi 7 Professional
 
#41

Re: Handling von Fehlern, Warnungen und Hints

  Alt 17. Sep 2008, 16:00
Globale Variablen werden schon immer mit 0 initialisiert.

Das ist ein dokumentiertes Verhalten und wird sicher nicht in Zukunft geändert.
Christian
Windows, Tokens, Access Control List, Dateisicherheit, Desktop, Vista Elevation?
Goto: JEDI API LIB & Windows Security Code Library (JWSCL)
  Mit Zitat antworten Zitat
Benutzerbild von SubData
SubData

Registriert seit: 14. Sep 2004
Ort: Stuhr
1.078 Beiträge
 
Delphi 11 Alexandria
 
#42

Re: Handling von Fehlern, Warnungen und Hints

  Alt 17. Sep 2008, 16:14
"Result" ist aber keine globale Variable und um die geht es hier
Ronny
/(bb|[^b]{2})/
  Mit Zitat antworten Zitat
Benutzerbild von MaBuSE
MaBuSE

Registriert seit: 23. Sep 2002
Ort: Frankfurt am Main (in der Nähe)
1.838 Beiträge
 
Delphi 10 Seattle Enterprise
 
#43

Re: Handling von Fehlern, Warnungen und Hints

  Alt 17. Sep 2008, 16:23
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.
(°¿°) MaBuSE - proud to be a DP member
(°¿°) MaBuSE - proud to be a "Rüsselmops" ;-)
  Mit Zitat antworten Zitat
Dezipaitor

Registriert seit: 14. Apr 2003
Ort: Stuttgart
1.701 Beiträge
 
Delphi 7 Professional
 
#44

Re: Handling von Fehlern, Warnungen und Hints

  Alt 17. Sep 2008, 16:32
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.
Christian
Windows, Tokens, Access Control List, Dateisicherheit, Desktop, Vista Elevation?
Goto: JEDI API LIB & Windows Security Code Library (JWSCL)
  Mit Zitat antworten Zitat
Benutzerbild von Chemiker
Chemiker

Registriert seit: 14. Aug 2005
1.859 Beiträge
 
Delphi 11 Alexandria
 
#45

Re: Handling von Fehlern, Warnungen und Hints

  Alt 17. Sep 2008, 18:55
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. :

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
wer gesund ist hat 1000 wünsche wer krank ist nur einen.
  Mit Zitat antworten Zitat
Dezipaitor

Registriert seit: 14. Apr 2003
Ort: Stuttgart
1.701 Beiträge
 
Delphi 7 Professional
 
#46

Re: Handling von Fehlern, Warnungen und Hints

  Alt 17. Sep 2008, 19:59
Ich glaube, wenn du ein neues Thema aufmachst mit deine Frage, dann können dir sicher mehr Leute helfen.
Christian
Windows, Tokens, Access Control List, Dateisicherheit, Desktop, Vista Elevation?
Goto: JEDI API LIB & Windows Security Code Library (JWSCL)
  Mit Zitat antworten Zitat
Benutzerbild von Chemiker
Chemiker

Registriert seit: 14. Aug 2005
1.859 Beiträge
 
Delphi 11 Alexandria
 
#47

Re: Handling von Fehlern, Warnungen und Hints

  Alt 17. Sep 2008, 20:25
Hallo Dezipaitor,

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
wer gesund ist hat 1000 wünsche wer krank ist nur einen.
  Mit Zitat antworten Zitat
Dezipaitor

Registriert seit: 14. Apr 2003
Ort: Stuttgart
1.701 Beiträge
 
Delphi 7 Professional
 
#48

Re: Handling von Fehlern, Warnungen und Hints

  Alt 17. Sep 2008, 20:36
Ah ok. Da hab ich die lange Tradition von Missverständnissen nur vortgeführt
Christian
Windows, Tokens, Access Control List, Dateisicherheit, Desktop, Vista Elevation?
Goto: JEDI API LIB & Windows Security Code Library (JWSCL)
  Mit Zitat antworten Zitat
Benutzerbild von MaBuSE
MaBuSE

Registriert seit: 23. Sep 2002
Ort: Frankfurt am Main (in der Nähe)
1.838 Beiträge
 
Delphi 10 Seattle Enterprise
 
#49

Re: Handling von Fehlern, Warnungen und Hints

  Alt 18. Sep 2008, 09:27
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.
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.
(°¿°) MaBuSE - proud to be a DP member
(°¿°) MaBuSE - proud to be a "Rüsselmops" ;-)
  Mit Zitat antworten Zitat
Benutzerbild von HeikoAdams
HeikoAdams

Registriert seit: 12. Jul 2004
Ort: Oberfranken
661 Beiträge
 
FreePascal / Lazarus
 
#50

Re: Handling von Fehlern, Warnungen und Hints

  Alt 18. Sep 2008, 10:26
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.

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 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
if a <= b then nur
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.
Jeder kann ein Held werden und Leben retten!
Einfach beim NKR oder der DKMS als Stammzellenspender registrieren! Also: worauf wartest Du noch?
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 5 von 9   « Erste     345 67     Letzte »    


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:23 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