#include <iostream>

int* f() {
	int x=10;
	return &x;
}

int main() {
	std::cout<< * f() <<std::endl;
}

kann mir jemand erklären, warum der Code überhaupt funktioniert? Die Funktion ermittelt die Adresse einer lokalen Variablen und mit "* f()" kann ich den Zeiger darauf wieder dereferenzieren, obwohl die Variable doch schon zerstört sein müsste. Es wird komischerweise jedoch lediglich eine Warnung ausgegeben:

In function ‘int* f()’:
warning: address of local variable ‘x’ returned

Danke

zufall das es funktioniert

Jap.
Es KANN funktionieren, muss aber nicht.

Es funktioniert noch so einiges, aber das heisst nicht, dass es das immer tut.

Interessant. Ich dachte nur, dass der g++ (4.2) bei solchen einfachen Dingen standardkonform bleiben würde.

und?

Interessant. Ich dachte nur, dass der g++ (4.2) bei solchen einfachen Dingen standardkonform bleiben würde.

tut er doch auch?

Naja, wenns Zufall ist, ists kein Standardverhalten, oder?

In C++ gibt es einiges das undefiniert ist, aber deshalb ist es dennoch hat das nichts mit Standardkonformität zu tun (C++ Standard).

Ok, wieder was gelernt.
Aber wird das dann nicht ein bisschen inkonsistent mit der Speicherverwaltung?

Wieso? C++ ist hier sehr konsequent: Dein Fall ist undefiniert (Das Objekt auf das der Zeiger zeigt existiert nicht mehr, und in deinem Fall wurde der Speicher einfach seit dem Freigeben nicht wieder überschrieben; Sprich du greifst auf Datenmüll zu der zufälligerweise noch dem alten Stand entspricht).

Speicher wird nicht nach der Freigabe ausgenullt oder so.

cu André

Soweit ichs verstanden habe, kann der Speicher nach Funktionsende und damit nach "Zerstörung" der lokalen Variablen wieder andersweitig vom BS verwendet und beschrieben werden. Wenn ich jetzt mit dem Zeiger auf diesen Inhalt zugreife, benutze ich nicht mehr den Wert, den ich eigentlich benutzen will. Also ist das Verhalten undefiniert. Evtl. steht an der Stelle nicht mal mehr ein int. Dann stimmt auch der int-Zeiger vom Typ her nicht mehr überein. Meinst du das?

Das ist eine mögliche Variante von undefiniert, kommt aber nicht zum eigentlichen Punkt. Jede Verwendung des Zeigerwertes (und da der Rückgabewert der Funktion ein rvalue ist bedeutet das hier: jede beliebige Operation mit dem Funktionsaufruf, die diesen Wert nicht verwirft (=cast nach void, ,-Operator, Nicht-Verwendung des Funktionswertes) ist undefiniert. Wie eine konkrete Implementation hier reagiert, stellt dann nur eine Möglichkeit dar. Es gibt einen praktisch bedeutsamen analogen Fall:

int* p = new int;
delete p;

Visual C++ (wie wohl auch andere Compiler) verändert im Debug-Modus beim delete das Zeigerobjekt p (das ist erlaubt, obwohl diese Veränderung durchaus beobachtbar sein kann - wir könnten ja p einfach als rohen Speicher anfassen und untersuchen, per memcmp und Ähnlichem). Der Wert, den p dann erhält, zeigt üblicherweise auf nicht existenten Speicher um dann eine Zugriffsverletzung auszulösen. Der Punkt dabei ist, dass der Wert p nach dem delete nichts mit dem davor zu tun hat. Ein vergleichbarer Vorgang (sogar problemloser, da wir hier nicht auf die Repräsentation zugreifen können) ist durchaus bei der Rückkehr aus der Funktion denkbar. Der bloße Versuch, diesen Wert z.B. zu dereferenzieren ist dann schon problematisch, zum Lesen irgendeines Wertes kommen wir gar nicht erst. Und das ist nur eine Möglichkeit, wie eine Implementation hier reagieren könnte (eine Andere wäre z.B. bei einem Interpreter, dass der Wert der Gleiche ist, aber nicht mehr mit einer realen Adresse verknüpft ist - und wenn ich länger drüber nachdenke, fallen mir sicher noch mehr Szenarien ein).

Also camper, dass eine Implementierung den Wert von "p" ändern darf beim delete ist mir neu. MSVC macht das auch *nicht*. MSVC überschreibt nur den Speicher der freigegeben wurde mit 0xDD, allerdings nicht die Zeigervariable selbst.

bin mir ziemlich sicher, das die debugging-rtl nach dem delete den pointer auf 0xfeeefeee zeigen lässt.

hustbaer schrieb:

Also camper, dass eine Implementierung den Wert von "p" ändern darf beim delete ist mir neu. MSVC macht das auch *nicht*. MSVC überschreibt nur den Speicher der freigegeben wurde mit 0xDD, allerdings nicht die Zeigervariable selbst.

bin mir ziemlich sicher, das die debugging-rtl nach dem delete den pointer auf 0xfeeefeee zeigen lässt.

Ja? Also bei mir wird der Speicher angefasst und auf 0xFEEE gesetzt, und nicht der Pointer selbst.

Ja? Also bei mir wird der Speicher angefasst und auf 0xFEEE gesetzt, und nicht der Pointer selbst.

ja, hast recht. ich hab mich an "access violation reading address 0xfeeefeee" erinnert. das war aber ein pointer in einem gelöschten objekt, kein alleinstehender pointer.

Tachyon schrieb:

Ja? Also bei mir wird der Speicher angefasst und auf 0xFEEE gesetzt, und nicht der Pointer selbst.

ja, hast recht. ich hab mich an "access violation reading address 0xfeeefeee" erinnert. das war aber ein pointer in einem gelöschten objekt, kein alleinstehender pointer.

Ich kann es jetzt auch gerade nicht nachvollziehen, allerdings MSDN delete Operator (C++)

If the operand to the delete operator is a modifiable l-value, its value is undefined after the object is deleted.

"undefined" meint hier wahrscheinlich "indeterminate" in standardesisch.

Was die Standardkonformität dieses Verhaltens angeht, muss ich noch mal recherchieren.

Nö, ok, wenn das so im Standard steht dann wird das schon gelten. Krass :)...

Vielleicht wollten sie damit einer "delete setzt auf 0"-Implementierung die Hintertür auflassen.

Gruß,

Simon2.

Ich glaube mich zu erinnern dass im Standard irgendwo steht dass man einen Zeiger der auf etwas zeigt was bereits gelöscht wurde, nichtmehr anfassen darf, mit der einzigen Ausnahme dass man ihn überschreiben darf. Und irgendwo las ich mal dass vermutlich die Überlegung dahinter bzw. der Grund dafür jene(r) ist, dass es Plattformen gibt bzw. geben könnte, wo bereits das Laden eines ungültigen Zeigers in ein Register zu einem Problem führen könnte. (Weil es z.B. das Segment bzw. die Seite auf die der Zeiger verweist garnichtmehr gibt, und eine Gültigkeitsprüfung schon beim Laden in ein Register erfolgt, nicht erst bei der Dereferenzierung.) Auf solchen Plattformen wäre es dann einfach doof für die Compiler Entwickler wenn es erlaubt wäre den Wert nach einem delete noch anzufassen.

Da man den Wert also nichtmehr anfassen darf kann man im Standard auch gleich sagen er ist danach undefiniert, weil's ja eh egal ist -- "legal" kann man ja eh nixmehr damit machen.