IDE: Compiler Einstellung für nicht initialisierte Variablen

[Athris]

Der Quellcode ist tatsächlich sehr alt (bestimmt über 15 Jahre). Das die Qualität des Codes eher mangelhaft ist, ist mir bewusst

Die Frage ist nur warum XE2 niemals eine Zugriffsverletzung anzeigt (ist halt nie aufgefallen) und Delphi 10.4 immer eine Zugriffsverletzung anzeigt.

[jaenicke]

Zitat von Athris:

Die Frage ist nur warum XE2 niemals eine Zugriffsverletzung anzeigt (ist halt nie aufgefallen) und Delphi 10.4 immer eine Zugriffsverletzung anzeigt.

Das ist eben Zufall. Da steht nun zufällig etwas im Speicher, was beim Zugriff eine nicht zugreifbare Adresse ist. Du hattest vorher schlicht Glück, dass in der Variablen ein Wert stand, von dem aus eine Adresse berechnet werden konnte, an der ein Zugriff möglich war. Und dass an der Stelle dann etwas war, das man in dem String nicht sehen konnte / nicht bemerkt wurde.

Wichtig ist vor allem, dass du keine Compilermeldungen (Variable nicht initialisiert, ...) ignorierst, wenn du die Anwendung erzeugst. Damit hast du schon viele mögliche Fehlerquellen vermieden.

[himitsu]

Es kommt drauf an, was da im Speicher/Stack steht.

Wenn da irgendwas stand, was als Pointer interpregiert und mit einem kleinen Offset versehen (zu FHandle) auf reservierten Speicher zeigt, dann kann das als HWND für WM_GETTEXT genommen werden.
Selbst wenn dieses "HWND" ungültig ist, würde es keinen Fehler geben, da Delphi davon das Result/GetLastError nicht auswertet und somit nur einen Leertext liefert.

[Athris]

Danke für eure Antworten, doch bleibe ich etwas skeptisch bei der Antwort "Es ist zufall".

Das kann kein Zufall sein. Der Programmabschnitt ist jahrelang bei über 150 Kunden im Einsatz gewesen. Auch bei uns selbst wurde der Abschnitt diverse mal aufgerufen und es kam NIE zu einer Zugriffsverletzung.

Beim neuen Delphi 10.4 kommt die Zugriffsverletzung jedes mal. Immer. Das kann doch kein Zufall sein.

Oder hat es etwas damit zu tun das wir bei XE2 immer nur in 32 bit kompiliert haben und nun beim 10.4 in 64bit kompilieren?

[himitsu]

Für lokale Variablen und Result wird Speicher nicht initialisiert. (Ausnahme sind gemanagte Typen wie String oder Interface, wo Delphi von sich aus das Speichermanagement sicherstellen muß)

Sie haben also den Wert, welcher ein vorhergehender Funktionsaufruf dort auf dem Stack hinterlassen hatte.


Es "kann" immer der selbe Wert sein, wenn die Aufrufe in gleicher Reihenfolge sind, aber es muß nicht und somit ist der Wert "unbestimmt", also zufällig.
Und wenn ein neuer Compiler anderen Code erzeugt oder Variablen anders im Speicher ablegt, dann ist es nunmal plötzlich anders.

[Athris]

Mit der Antwort kann ich leben, vielen Dank!

[Der schöne Günther]

Ich kann nichts mehr hinzufügen, genauso wie erklärt ist es.

Ich kann nur aus eigener Erfahrung berichten dass wir exakt den Fall auch hatten- Eine alte, nicht mehr gewartete Delphi-DLL mit so vielen Warnmeldungen über nicht initialisierte Variablen dass da auch keiner mehr geschaut hat. Lief viele Jahre lang.

Als sie eines Tages durch einen neueren Delphi-Compiler gejagt wurde gingen vereinzelte Dinge nicht mehr, keiner wusste weshalb. Lösung war exakt das gleiche: Eine nicht initialisierte Variable führte zu einer Zugriffsverletzung, und früher hat es bei einem älteren Compiler grade so gepasst dass nichts in sich zusammenbrach...

[himitsu]

Jo, 64 Bit ist immer mit StackFrames und es gibt auch nur noch eine Calling-Convension (sieht witziger Weise fast wie die von Delphi aus ),

aber es macht die Sache mit dem Stack viel einfacher.


Und zusätzlich seit 'ner kurzen Weile auch direkt eine WinAPI, zum lesen des Stacks und der Debuginfos.
Nur blöd, dass Delphi seine eigenen Debuginfos hat und man nicht aktivieren kann, dass man auch die "normalen" mit im Programm einkompiliert haben möchte.

[jaenicke]

Zitat von Athris:

Oder hat es etwas damit zu tun das wir bei XE2 immer nur in 32 bit kompiliert haben und nun beim 10.4 in 64bit kompilieren?

Da gibt es diverse Unterschiede. Einer davon, der für die Exceptionbehandlung wichtig ist:
Bei 32-Bit Programmen ist der Stackframe nicht fest. Deshalb ist es nicht so einfach möglich, nach einem Fehler einen sauberen Stacktrace aufzubauen.
Bei 64-Bit Programmen gibt es dafür eindeutige Vorgaben, so dass man in der Regel auch zuverlässige Stacktraces bekommt.