Wilde Zeiger in den Griff bekommen
-
Hehe ich habe befürchtet, dass so eine Antwort kommt
Ich kann die Problematik bestenfalls in ein anderes Beispiel verpacken, grundsätzlich bleibt sie aber gleich. Es geht darum, wie man A) eine Zeigervariable evaluieren kann oder
eine Win32-Ausnahme abfängt. Mein Beispiel oben ist ja bereits auf das Mindestmaß heruntermodelliert. Es ist nur ein Modell, welches das Problem veranschaulichen soll, darum bitte nur mit der Problematik befassen, nicht mit dem Modell an sich
-
Ich verstehe das Problem nicht.
Ich definiere in meinem Programm einen Zeiger und muß den validieren ? Warum ?
Eigentlich müßte ich das doch selbst wissen ...
-
Scheinbar war ich nur zu blöd um __try richtig anzuwenden. Nun funktioniert es erfreulicherweise doch!
-
Es funktioniert nicht, es kommt nur auf den ersten Blick so vor. Du hast im Prinzip die IsBadReadPtr nachimplementiert. Sie ist aus gutem Grund deprecated, siehe auch http://blogs.msdn.com/oldnewthing/archive/2006/09/27/773741.aspx
-
@mikeem: Du löst dadurch bloss dein Problem nicht! Das eigentliche Problem ist nämlich, dass du überhaupt irgendwo Zeiger hast, die auf etwas ungültiges zeigen können.
Abzufragen ob ein Zeiger auf eine "gültige" Adresse zeigt reicht nicht. Warum? z.B. schonmal weil Speicherbereiche wiederverwendet werden. Und weil, wenn es eine vollkommen zufällige Adresse ist, an der Stelle auch ganz zufällig Speicher hinterlegt sein kann. Der dann aber ganz zufällig auf irgendwas ganz anderes zeigt, als du eigentlich ansprechen willst.Kurz: dein Programm wird langfristig nicht stabil funktionieren wenn du solche Hacks verwendest.
Lös das ursprüngliche Problem: beseitige die Möglichkeit dass du überhaupt irgendwo an einen "ungültigen" Zeiger kommst. Dann brauchst du diese Hacks nimmer, und dein Programm wird stabil laufen. Vorausgesetzt du hast nich noch andere Fehler drinnen natürlich.
-
Du kannst natürlich deinen Zeiger am Anfang auf NULL setzen und später auf NULL überprüfen.
-
@mikeem: Ich kann Dir nur raten zu tun was hustbaer Dir geraten hat.
-
Danke für die Infos, werde mir das nochmal ganz genau anschauen!
-
hustbaer schrieb:
Kurz: dein Programm wird langfristig nicht stabil funktionieren wenn du solche Hacks verwendest.
Gegen das Verwenden eine korrekt arbeitenden Prüffunktion an sich spricht IMO erst mal nichts. Ich nutze solche Funktionalität, um Fehler im Code frühzeitig zu finden. Denn Lesbarkeit des Zeigers ist zwar keine hinreichende, aber doch notwendige Bedingung für einen fehlerfreien Programmverlauf. Ich ziehe dann z.B. C++ exceptions den SEH-exceptions, die ja sonst geworfen werden, vor (damit die Destruktoren aufgerufen werden können). Fangen tue ich sie normalerweise nicht, da sie dann sowieso auf Programmierfehler zeigen, und ich den Call Stack im Dump sehen möchte.
-
Superlexx schrieb:
hustbaer schrieb:
Kurz: dein Programm wird langfristig nicht stabil funktionieren wenn du solche Hacks verwendest.
Gegen das Verwenden eine korrekt arbeitenden Prüffunktion an sich spricht IMO erst mal nichts. Ich nutze solche Funktionalität, um Fehler im Code frühzeitig zu finden. Denn Lesbarkeit des Zeigers ist zwar keine hinreichende, aber doch notwendige Bedingung für einen fehlerfreien Programmverlauf. Ich ziehe dann z.B. C++ exceptions den SEH-exceptions, die ja sonst geworfen werden, vor (damit die Destruktoren aufgerufen werden können). Fangen tue ich sie normalerweise nicht, da sie dann sowieso auf Programmierfehler zeigen, und ich den Call Stack im Dump sehen möchte.
Ja. Blub.
Der OP schreibt im ersten Beitrag...:mikeem schrieb:
Wenn man Pech hat, ist die obige Adresse falsch, und das Programm stürzt mit einer Win32 Ausnahme ab. (...)
Für mich bedeutet das etwas deutlicher formulier: mein Programm hat Fehler, und die will ich jetzt maskieren, indem ich da mit __try (oder ähnlichem) rumfummel.
Gehst du davon aus dass ich das falsch interpretiere?
