C++ 03/11 standard, dangling pointer verwenden = undefined oder implementation defined?



  • Hallo,
    wie im Betreff angegeben

    T* foo = new T();
    T* bar = foo ;
    delete foo ;
    
    bar->machWas() ; // undefined oder implementation defined
    

    ist das verwenden eines dangling pointers undefiniert, oder vom Compiler hHersteller abhängig?

    und gab es hier änderungen? Ich fand diese
    http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#1438
    jedoch hier,
    http://cs.nyu.edu/courses/summer11/G22.2110-001/documents/c++2003std.pdf
    finde ich nichts dazu. 3.7.4 ist recht kurz im original standard.

    oder schau ich sowieso bei der falschen Stelle nach?



  • Das ist doch völlig irrelevant. Lass es!


  • Mod

    Unter der Annahme, dass machWas eine nicht-statische Memberfunktion ist: Undefiniert.

    Vielleicht verstehe ich auch deine Frage nicht ganz richtig, denn die zitierte Passage hat nicht direkt etwas damit zu tun, wie ich deine Frage verstanden habe.



  • Es geht dort nicht um das Dereferenzieren (bei dir also bar->machwas , sondern um die Verwendung des nicht-dereferenzierten Pointers ("This includes not only dereferencing the pointer but even just fetching its value."), also sowas

    T* foo = new T();
    delete foo;
    T* dieseKopieIstUB = foo;
    

    Hier wird also foo nochmal verwendet, nachdem foo deleted wurde. Der Artikel stellt die Frage, ob es nötig ist, dass obige Kopie UB ist. Es geht nicht darum, die Kopie auch zu dereferenzieren, was klar UB ist.



  • primär geht es darum wie ich in einen Bug Report priorisiere.

    es wird ein Pointer verwendet der zu einem Objekt zeigt welches gelöscht wurde

    Verwendung eines invalid pointer value

    http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf
    6.3.2.3 Pointers Punkt 20 meint undefiniert.

    Das meine ich auch.

    Es gibt Kollegen die meinen es ist garantiert das es sofort crashed.
    (crash is ok, fix daher später)

    Ich will ich den Bug raufpriorisieren weil Crash => Restart eben nicht garantierte, sondern nur sehr wahrscheinlich ist, meiner bescheidenen Meinung nach.

    Ich brauch aber ein Dokument auf welches ich verweisen kann, am besten eben C++ Standard, (Version 03), damit das ohne weitere Diskussion durchgeht.



  • Beweis durch Widerspruch:
    Mach eine main drum und lass es auf einem beliebigen System als Releasebuild laufen. Ich bin mir ziemlich sicher, dass das immer ohne crash funktioniert.



  • kurze_frage schrieb:

    Ich brauch aber ein Dokument auf welches ich verweisen kann, am besten eben C++ Standard, (Version 03), damit das ohne weitere Diskussion durchgeht.

    Das Dokument hast du ja schon. Es ist undefined behavior. Es kann passieren das da was crasht, du hast aber auch ne gute Chance das es einfach weiterläuft und irgendwo anders dann ggf Daten zerschossen werden wenn du pech hast.


  • Mod

    Es gibt Kollegen die meinen es ist garantiert das es sofort crashed.

    So eine Art von Verhalten gibt es im Standard nicht, weil es völlig unklar wäre, was als Crash gilt, und welche Art von Crash überhaupt auf allen Plattformen implementierbar ist. Deine Platform könnte einen Crash festlegen. Auf einem gewöhnlichen System generiert bspw. die MMU einen trap, welcher dann über dein OS als Segfault gemeldet wird. Auf einem System ohne entsprechende Hardware wird es vielleicht anders ausgehen. Dieses Systemabhängige Ausnahmeverhalten ist als "undefiniertes Verhalten" im Standard zu finden.

    Ich brauch aber ein Dokument auf welches ich verweisen kann, am besten eben C++ Standard, (Version 03), damit das ohne weitere Diskussion durchgeht.

    Es macht wenig Sinn sich auf C++03 zu beschränken, wenn die Chance besteht, defekte Teile zu zitieren. Wenn die Teile nicht defekt sind, hätte man gleich C++14 zitieren können (welches im Übrigen auch eher auf das Verhalten aktueller Implementierungen zutrifft, und ich hoffe doch stark, dass ihr nicht mit VS2005 arbeitet).



  • Xebov schrieb:

    Das Dokument hast du ja schon. Es ist undefined behavior. Es kann passieren das da was crasht, du hast aber auch ne gute Chance das es einfach weiterläuft und irgendwo anders dann ggf Daten zerschossen werden wenn du pech hast.

    ja, hab sogar was besseres gefunden, nutzte nur leider nix.

    Arcoth schrieb:

    So eine Art von Verhalten gibt es im Standard nicht, weil es völlig unklar wäre, was als Crash gilt, und welche Art von Crash überhaupt auf allen Plattformen implementierbar ist. Deine Platform könnte einen Crash festlegen. Auf einem gewöhnlichen System generiert bspw. die MMU einen trap, welcher dann über dein OS als Segfault gemeldet wird. Auf einem System ohne entsprechende Hardware wird es vielleicht anders ausgehen. Dieses Systemabhängige Ausnahmeverhalten ist als "undefiniertes Verhalten" im Standard zu finden.

    ja eben, das denke ich auch und ich bin der Meinung wenn man Qualität liefern sollte dann macht man einfach den existierenden fix noch ins bevorstehende Release weil das geht schneller als ewig drüber zu diskutieren. (cherrypick 5 Minuten, Testen 0,5 Tage 1 Person, Diskussion= mehrere Leute sind den halben Tag, eventuell länger, abgelegt)

    Arcoth schrieb:

    Es macht wenig Sinn sich auf C++03 zu beschränken, wenn die Chance besteht, defekte Teile zu zitieren. Wenn die Teile nicht defekt sind, hätte man gleich C++14 zitieren können (welches im Übrigen auch eher auf das Verhalten aktueller Implementierungen zutrifft, und ich hoffe doch stark, dass ihr nicht mit VS2005 arbeitet).

    da hast du recht, nur muss es jetzaein C++03 document sein weil sonst sagt mir der Code Author das ich von was ganz anderem spreche.
    gcc, nicht die aktuellste weil mehrerer Plattformen, x86, unterschiedliche arm, die embedded Welt bewegt sich langsam.

    hier gibt es etwas dazu,
    http://cs.nyu.edu/courses/summer11/G22.2110-001/documents/c++2003std.pdf

    3.7.3.2 Punkt 4 das selbe wie im C Standard, nur mit einer Fussnote das Hersteller einen vielleicht einen Crash implementieren ... das reichte, wir fixen später,
    egal, ich hab es dokumentiert, es ist nur ein Job, irgendwann lande ich in einem Umfeld die Qualität ähnlich ernst nimmt ... bis dahin hoffe ich dass ich mich nicht zu sehr anpasse, und versuche zu lernen warum es besser sein kann wenn viele Leute einen Halben Tag lang reden und nix tun, als 1 Person einen halben Tag lang arbeitet und etwas repariert 😉


Log in to reply