array[1..10] auf Wert prüfen?

[bernau]

Schau mal hier

Dort ist extra angegeben, dass die Variable nach Schleifendurchlauf undefiniert ist.

Durch Codeoptimierung des Compilers "könnte" die Variable nicht den erwarteten Wert haben. Nur weil du jetzt keinen Codeschnipsel bekommst, der das zeigen kann, bedeutet es nicht, dass es nicht doch passieren kann.

Außerdem kann mit einer neuen Compilerversion das Verhalten des bestehenden "funktionierenden" Codes verändert werden. Siehst du schon, dass FPC und Delphi den Code unterschiedlich ausführen.

Ich wäre da sehr vorsichtig.

[KodeZwerg]

Zitat:

Zitat von bernau (Beitrag 1410689)

Dort ist extra angegeben, dass die Variable nach Schleifendurchlauf undefiniert ist.

Nee.

Zitat:

FOR-Loop variable '%s' may be undefined after loop

may = könnte.
Lustig das Du sowas für meine Delphi Version gefunden hast.

[bernau]

Zitat:

Zitat von KodeZwerg (Beitrag 1410693)

Nee.

Zitat:

FOR-Loop variable '%s' may be undefined after loop

may = könnte.

Das reicht doch schon um eine Variable als undefiniert anzusehen. Außer ich weiß, wann die Variable undefiniert sein könnte.

:roll:

[KodeZwerg]

Das "may/könnte" gibt eher an das es am Programmierer liegt dafür Sorge zu tragen ob etwas un-/definiert ist.

[Schokohase]

Zitat:

Zitat von KodeZwerg (Beitrag 1410710)

Das "may/könnte" gibt eher an das es am Programmierer liegt dafür Sorge zu tragen ob etwas un-/definiert ist.

Das „may“ gibt an, dass bei der Entwicklung des Compilers kein Wert darauf gelegt wird, dass in der Schleifenvariable nach der Schleife ein bestimmter Wert enthalten ist auf den man sich verlassen kann.

Wer sich darauf verlässt, ist sozusagen von allen guten Geistern verlassen.

[KodeZwerg]

Schlussendlich, da es ein "may" ist, könnten alle Aussagen zutreffen. Punkt, Ende und abgehakt.

[himitsu]

Egal ob "geht garnicht" oder "geht eventuell nicht",
das Verhalten ist so nicht vorgegeben, also kann/darf man sich nicht auf sowas verlassen.

Außer in Ausnahmefällen, kann darf sowas niemals "immer" in Produktivcode verwendet werden.

[Sherlock]

Zitat:

Zitat von KodeZwerg (Beitrag 1410714)

Schlussendlich, da es ein "may" ist, könnten alle Aussagen zutreffen. Punkt, Ende und abgehakt.

Das mag jetzt hart klingen, vielleicht verletzend, muss aber so gesagt werden:
Ein Entwickler, der einen Fall ignoriert, dessen Auftreten explizit erwähnt wird, sollte den Beruf wechseln.

In diesem Sinne, nix für ungut. Hier haben sich alle Lieb.

Sherlock

[KodeZwerg]

Bestimmt ist es so wie Ihr schreibt und jede Compiler Warnung "Variable X may not be initialized" ist zu 100% definitiv nicht initialisiert.... einfach nur dumm so eine Aussage. Klar sollte man sich Gedanken machen wieso der Compiler mir so etwas erzählt. Aber es bleibt bei einem MAY. Apropo may, mayday mayday, bin raus hier.

Mir ging es nur um Bernaus Übersetzung und nicht irgend welche Code-Schnippsel oder irgend ein anderer Zusammenhang.

[Neutral General]

Hier haben sich in einem Projekt eine ganze Menge Warnungen dieser Art angesammelt und wir sind jetzt dran die ganzen Warnungen etc anzugehen um potenzielle Fehlerquellen auszuschließen.
Habe schon unzählbare Warnungen dieser Art korrigiert und jedes einzelne Mal hatte der Compiler Recht und die Variable WAR nicht initialisiert.

Von daher kann ich dir erfahrungsgemäß sagen, dass zu 99-100% diese Warnung ernst zu nehmen ist und wenn du glaubst der Compiler hat Unrecht dann ist das Problem wahrscheinlich dass der Compiler mehr weiß als du (und Recht hat).
Ich hatte jetzt den Fall dass viele dieser Warnungen aufgrund von "Glück" und "Magie" in einem 32-Bit Programm keinen Ärger machen.
Nachdem ich das Programm dann als 64-Bit exe compiliert habe, haben sich eine ganze Menge dieser Warnungen in ziemlich zuverlässige Laufzeitfehler verwandelt.