C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Undefiniertes Verhalten Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ (German) View previous topic :: View next topic   Author Message Dirk Clemens Guest Posted: Tue Sep 21, 2004 8:30 pm    Post subject: Undefiniertes Verhalten Habe heute den folgenden Code gefunden: (abgespeckt) ---------- char * buf = malloc(size); if (buf) { char *ptr = buf - 1; // <<<<<<< char end_buf = ptr + size; while ( ptr < end_buf && bedingung() ) { char ch; ... *++ptr = ch; } *++ptr = 0; } ------------- Ist das Verhalten von 'ptr' definiert? Hintergrund: ptr wird der Wert buf-1 zugewiesen, der dann natürlich ausserhalb eines gültigen Speicherbereiches liegt. Vor der ersten Dereferenzierung wird der Zeiger aber wieder inkrementiert. Oder anders gefragt: Ist 'buf - 1 + 1 == buf' immer wahr, auch wenn das Zwischenergebnis 'buf - 1' ins Nierwana zeigt? Lemmi P.S.: Mir ist klar, das man dass mit Posinkrement einfach sauber lösen kann. -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Boris Glawe Guest Posted: Tue Sep 21, 2004 9:16 pm    Post subject: Re: Undefiniertes Verhalten Quote: Ist das Verhalten von 'ptr' definiert? Eigentlich schon. Man kann Pointer immer inkrementieren oder dekrementieren, auch wenn sie sinnlose Werte enthalten. Allerdings sollte man so etwas auf gar keinen Fall nachahmen. Verändert man später den Code ein wenig, dann wird ganz schnell der falsche Pointer derefenziert und man hat einen schwer zu findenden Segmentation fault. In deinem Beispiel werden solche Konstrukte vollkommen ohne Not benutzt - was von ziemlich schlechtem Programmierstil zeugt. Zuletzt habe ich solchen Code in einer Informatikklausur gesehen (das hier habe ich selbst erfunden): Wie lautet der Wert von x nach folgendem Aufruf? func(int * x){ *x = *x-- == 5 ? x++ : x--; } int main(){ int array[] = {1,2,3,4,5,6,7,8,9}; int x = 5; if (++x != array[x--] || func(&x) ) { x %=3; } } -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Lutz Jacob Guest Posted: Tue Sep 21, 2004 9:17 pm    Post subject: Re: Undefiniertes Verhalten Am Tue, 21 Sep 2004 22:30:05 +0200 schrieb Dirk Clemens: Quote: Ist das Verhalten von 'ptr' definiert? Der Standard sagt da ziemlich eindeutig _nein_. Es ist eigentlich auch mit etwas Überlegung einzusehen, dass man für Arrays beliebiger Typen nur im Bereich Anfang bis Ende+1 eine Pointer-Arithmetik ohne Überlauf/Unterlauf garantieren kann. ciao Lutz -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Horst Kraemer Guest Posted: Wed Sep 22, 2004 5:29 am    Post subject: Re: Undefiniertes Verhalten Boris Glawe <boris (AT) boris-glawe (DOT) de> wrote: Quote: Ist das Verhalten von 'ptr' definiert? Eigentlich schon. Man kann Pointer immer inkrementieren oder dekrementieren, auch wenn sie sinnlose Werte enthalten. Der C++-Standard sagt eindeutig etwas anderes. Bei einer Addition oder Subtraktion pointer +- ganzzahliger Wert oder Inkrementierung oder Dekrementierung muessen Ursprungswert und Ergebnis in dasselbe Array oder 1 Element hinter das letzte Arrayelement zeigen. 5.7, 5, letzter Satz If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow, otherwise the behavior is undefined. 'Evaluation' bezieht sich hier auf die Auswerten der Zeigeroperation, nicht auf das Dereferenzieren. MfG Horst -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Heinz Saathoff Guest Posted: Wed Sep 22, 2004 7:18 am    Post subject: Re: Undefiniertes Verhalten Moin, Horst Kraemer schrieb... Quote: Der C++-Standard sagt eindeutig etwas anderes. Bei einer Addition oder Subtraktion pointer +- ganzzahliger Wert oder Inkrementierung oder Dekrementierung muessen Ursprungswert und Ergebnis in dasselbe Array oder 1 Element hinter das letzte Arrayelement zeigen. Muß in diesem Fall auch bei einer Indexberechnung entsprechend geklammert werden? Also bei sowas: int array[10]; int pre = -3; int post = 5; int *ptr0 = array + pre + post; // undefiniert? int *ptr1 = array + (pre + post); // definiert, da Klammern? Der Operator + wird ja von links nach rechts ausgewertet, dabei würde im Fall von ptr1 mit (array + pre) intern ein undefinierter Zwischenwert berechnet. - Heinz -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Heinz Saathoff Guest Posted: Wed Sep 22, 2004 7:26 am    Post subject: Re: Undefiniertes Verhalten Moin, Lutz Jacob schrieb... Quote: Der Standard sagt da ziemlich eindeutig _nein_. Soweit richtig Quote: Es ist eigentlich auch mit etwas Überlegung einzusehen, dass man für Arrays beliebiger Typen nur im Bereich Anfang bis Ende+1 eine Pointer-Arithmetik ohne Überlauf/Unterlauf garantieren kann. Unmittelbar einsichtig eigentlich nur für die Dereferenzierung, da dann in nicht allokierte Bereiche zugegriffen wird. Die Arithmetik auf Pointern wird auf den meisten gebräuchlichen Architekturen durchaus funktionieren, vor allem dann, wenn sizeof(int)==sizeof(void*) ist. - Heinz -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Rolf Magnus Guest Posted: Wed Sep 22, 2004 8:06 am    Post subject: Re: Undefiniertes Verhalten Heinz Saathoff wrote: Quote: Moin, Lutz Jacob schrieb... Der Standard sagt da ziemlich eindeutig _nein_. Soweit richtig Es ist eigentlich auch mit etwas Überlegung einzusehen, dass man für Arrays beliebiger Typen nur im Bereich Anfang bis Ende+1 eine Pointer-Arithmetik ohne Überlauf/Unterlauf garantieren kann. Unmittelbar einsichtig eigentlich nur für die Dereferenzierung, da dann in nicht allokierte Bereiche zugegriffen wird. Die Arithmetik auf Pointern wird auf den meisten gebräuchlichen Architekturen durchaus funktionieren, vor allem dann, wenn sizeof(int)==sizeof(void*) ist. Es kann auch komplett ungültige Zeigerwerte geben. Je nach Syststem kann die CPU auch bereits beim Laden eines solchen Adresswertes in ein Adressregister einen Interrupt auslösen, der das System veranlasst, dein Programm zu terminieren. -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Horst Kraemer Guest Posted: Wed Sep 22, 2004 9:12 am    Post subject: Re: Undefiniertes Verhalten Heinz Saathoff <hsaat (AT) despammed (DOT) com> wrote: Quote: Moin, Horst Kraemer schrieb... Der C++-Standard sagt eindeutig etwas anderes. Bei einer Addition oder Subtraktion pointer +- ganzzahliger Wert oder Inkrementierung oder Dekrementierung muessen Ursprungswert und Ergebnis in dasselbe Array oder 1 Element hinter das letzte Arrayelement zeigen. Muß in diesem Fall auch bei einer Indexberechnung entsprechend geklammert werden? Also bei sowas: int array[10]; int pre = -3; int post = 5; int *ptr0 = array + pre + post; // undefiniert? int *ptr1 = array + (pre + post); // definiert, da Klammern? Der Operator + wird ja von links nach rechts ausgewertet, dabei würde im Fall von ptr1 mit (array + pre) intern ein undefinierter Zwischenwert berechnet. Ich wuerde den Standard so interpretieren wie Du, d.h. dass das Verhalten des Ausdrucks array + pre + post alias (array + pre) + post undefiniert ist, weil das Verhalten des Teilausdrucks array+pre undefiniert ist. -- Horst -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Heinz Saathoff Guest Posted: Wed Sep 22, 2004 10:14 am    Post subject: Re: Undefiniertes Verhalten Moin, Rolf Magnus schrieb... Quote: Unmittelbar einsichtig eigentlich nur für die Dereferenzierung, da dann in nicht allokierte Bereiche zugegriffen wird. Die Arithmetik auf Pointern wird auf den meisten gebräuchlichen Architekturen durchaus funktionieren, vor allem dann, wenn sizeof(int)==sizeof(void*) ist. Es kann auch komplett ungültige Zeigerwerte geben. Je nach Syststem kann die CPU auch bereits beim Laden eines solchen Adresswertes in ein Adressregister einen Interrupt auslösen, der das System veranlasst, dein Programm zu terminieren. Das hab ich ja auch nicht bestritten. Genau deshalb sagt der Standard ja was von undefiniert. BTW, zu Zeiten des 286-er mit seg:ofs hat der MS-Compiler und auch der TopSpeed die Zeigerarithmetik in den 'general purpose' registern durchgeführt. Erst bei Dereferenzierung wurde ein Segmentregister beschrieben, was dann im protected mode zum Absturz führen konnte. Die Compilerbauer haben also schon bedacht, daß ungültige Segmentwerte zu Abstürzen führen können und deshalb nur beschrieben werden, wenn's unbedingt sein muß. Sein muß es erst bei der Dereferenzierung. - Heinz -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Thomas Dorner Guest Posted: Wed Sep 22, 2004 5:03 pm    Post subject: Re: Undefiniertes Verhalten Hallo Heinz! HS> wenn sizeof(int)==sizeof(void*) ist. Was durchaus auch in "gebräuchlichen Architekturen" nicht garantiert ist, daher möchte ich gerne noch mal explizit darauf hinweisen, so etwas sein zu lassen. Dieser Fehler wird seit Jahrzehnten immer wieder gerne gemacht und ist anscheinend nicht totzukriegen. Schon der alte cfront 1.irgendwas hat sowas intern gemacht. (Ich habe zu Uni-Zeiten mal spaßeshalber versucht, den auf einer 68000er Architektur zu portieren und bin genau an diesem Problem in vielen Sourcen gescheitert.) Viele Grüße, Thomas PS: Hier 4 und 8; g++ 3.3.3 auf Linux x86_64. -- From-Adresse wird nicht genutzt, Reply-To Adresse gilt nur 4 Wochen! -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Heinz Saathoff Guest Posted: Mon Sep 27, 2004 7:04 am    Post subject: Re: Undefiniertes Verhalten Moin, Lutz Jacob schrieb... Quote: Unmittelbar einsichtig eigentlich nur für die Dereferenzierung, da dann in nicht allokierte Bereiche zugegriffen wird. Die Arithmetik auf Nein, wenn man verlangt, dass bei Zeigerarithmetik niemals die Grenzen des Adressraumes überschritten werden dürfen, muss man genau das fordern, was im Standard steht. Der Standard verlangt das ja nicht, sondern sagt nur, daß es undefiniertes verhalten ist. BTW, der Zeiger darf sogar hinter dem allokierten Adressraum liegen, also int array[N]; int *ip = array+N; // ip ist definiert, darf aber // nicht dereferenziert werden! Quote: Stell Dir einfach vor, Du legst ein Array von T an, T *p = new T[n]; Sobald nun sizeof T größer ist als der Abstand zwischen dem Anfang des Adressraumes und p, verlässt Du mit (p-1) schon den Adressraum, d.h. meist landest Du dann bei einer Adresse mit (p-1)>p. Das wäre noch der gutartige Fall, würde bei einem Algorithmus wie dem des OP aber schon zu Unfug führen. Auf normalen Systemen braucht man sicherlich sehr große T, um wirklich Probleme zu haben, aber wie und warum soll man das im Standard formulieren. Mir ging es um das auf das auf vielen Maschinen (alle, die ich kenne, was aber wenige sind) eine Zeigerarithmetik wie bei unsigned Datentypen durchgeführt wird. Dort ist IIRC definiert, daß unsigned x=WERT; x -= beliebiger_unsigned; x += beliebiger_unsigned; ASSERT(x==WERT); immer erfüllt ist, auch wenn es zwischenzeitlich zu Überläufen kommt. Wenn Pointerarithmetik auf einer Maschine nach diesem Schema betrieben wird, dann ist in dem _konkreten_ Fall auch Dein Beispiel definiert, solange das Zwischenergebnis nur gespeichert wird, aber nicht dereferenziert oder für Vergleiche herangezogen wird. Aus diesem Grund meinte ich, daß es eben nicht 'unmittelbar einsichtig' ist, daß diese Pointerarithmetik außerhalb allokiertem Bereich zu undefiniertem Verhalten führt, weil es eben auf vielen Maschinen klappt! Es muß aber nicht klappen! Wenn also ein Compilerhersteller für irgendeine Maschine aus dieser Einschränkung Optimierungsmöglichkeiten ableiten kann, die bei Nichtbeachtung zu Abstürzen führt, darf er das. Quote: Der Zugriff auf das Element n+1 liegt dagegen immer nur um 1 Byte (nicht etwa sizeof T) hinter dem Ende des Arrays, d.h. solange das Array ein Byte unter der Grenze des Adressraumes endet, liefert (p+n) keinen Überlauf, bleibt also gültig und größer als p. Korrekt, obwohl (p+n) auch nicht dereferenziert werden darf. - Heinz -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Rolf Magnus Guest Posted: Mon Sep 27, 2004 10:14 am    Post subject: Re: Undefiniertes Verhalten Heinz Saathoff wrote: Quote: Moin, Lutz Jacob schrieb... Unmittelbar einsichtig eigentlich nur für die Dereferenzierung, da dann in nicht allokierte Bereiche zugegriffen wird. Die Arithmetik auf Nein, wenn man verlangt, dass bei Zeigerarithmetik niemals die Grenzen des Adressraumes überschritten werden dürfen, muss man genau das fordern, was im Standard steht. Der Standard verlangt das ja nicht, sondern sagt nur, daß es undefiniertes verhalten ist. Was soviel bedeutet wie daß er von einem konformen Programm verlangt, daß dieses sowas nicht tut. Quote: BTW, der Zeiger darf sogar hinter dem allokierten Adressraum liegen, also int array[N]; int *ip = array+N; // ip ist definiert, darf aber // nicht dereferenziert werden! Das gilt nur für den Fall N==1. Nur Zeiger, die maximal ein Element hinter das letzte des Arrays zeigen, sind erlaubt. "If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined." Quote: Stell Dir einfach vor, Du legst ein Array von T an, T *p = new T[n]; Sobald nun sizeof T größer ist als der Abstand zwischen dem Anfang des Adressraumes und p, verlässt Du mit (p-1) schon den Adressraum, d.h. meist landest Du dann bei einer Adresse mit (p-1)>p. Das wäre noch der gutartige Fall, würde bei einem Algorithmus wie dem des OP aber schon zu Unfug führen. Auf normalen Systemen braucht man sicherlich sehr große T, um wirklich Probleme zu haben, aber wie und warum soll man das im Standard formulieren. Mir ging es um das auf das auf vielen Maschinen (alle, die ich kenne, was aber wenige sind) eine Zeigerarithmetik wie bei unsigned Datentypen durchgeführt wird. Dort ist IIRC definiert, daß unsigned x=WERT; x -= beliebiger_unsigned; x += beliebiger_unsigned; ASSERT(x==WERT); immer erfüllt ist, auch wenn es zwischenzeitlich zu Überläufen kommt. Genauer gesagt ist das in der Norm gar nicht als Überlauf definiert. Quote: Wenn Pointerarithmetik auf einer Maschine nach diesem Schema betrieben wird, dann ist in dem _konkreten_ Fall auch Dein Beispiel definiert, solange das Zwischenergebnis nur gespeichert wird, aber nicht dereferenziert oder für Vergleiche herangezogen wird. Aus diesem Grund meinte ich, daß es eben nicht 'unmittelbar einsichtig' ist, daß diese Pointerarithmetik außerhalb allokiertem Bereich zu undefiniertem Verhalten führt, weil es eben auf vielen Maschinen klappt! Es muß aber nicht klappen! Wenn also ein Compilerhersteller für irgendeine Maschine aus dieser Einschränkung Optimierungsmöglichkeiten ableiten kann, die bei Nichtbeachtung zu Abstürzen führt, darf er das. Nicht mal unbedingt nur als Optimierung, sondern evtl. auch zur Sicherheit. Die Maschine meldet einen out-of-bounds pointer sofort, anstatt ihn vorerst zu ignorieren und dadurch einen Bug zu verschleiern. -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Rolf Magnus Guest Posted: Mon Sep 27, 2004 10:45 am    Post subject: Re: Undefiniertes Verhalten Rolf Magnus wrote: Quote: Der Standard verlangt das ja nicht, sondern sagt nur, daß es undefiniertes verhalten ist. Was soviel bedeutet wie daß er von einem konformen Programm verlangt, daß dieses sowas nicht tut. BTW, der Zeiger darf sogar hinter dem allokierten Adressraum liegen, also int array[N]; int *ip = array+N; // ip ist definiert, darf aber // nicht dereferenziert werden! Das gilt nur für den Fall N==1. Nur Zeiger, die maximal ein Element hinter das letzte des Arrays zeigen, sind erlaubt. Ok, das war Quatsch. Dein Zeiger zeigt ja für jedes N genau ein Element hinter das Array. Ich hatte in der zweiten Zeile das 'array' irgendwie als Ende des Arrays interpretiert. -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Heinz Saathoff Guest Posted: Mon Sep 27, 2004 10:46 am    Post subject: Re: Undefiniertes Verhalten Moin, Rolf Magnus schrieb... Quote: BTW, der Zeiger darf sogar hinter dem allokierten Adressraum liegen, also int array[N]; int *ip = array+N; // ip ist definiert, darf aber // nicht dereferenziert werden! Das gilt nur für den Fall N==1. Nur Zeiger, die maximal ein Element hinter das letzte des Arrays zeigen, sind erlaubt. Genau. Aber das ist auch bei anderen N als 1 der Fall! - Heinz -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Stefan Reuther Guest Posted: Mon Sep 27, 2004 6:13 pm    Post subject: Re: Undefiniertes Verhalten Rolf Magnus wrote: Quote: Heinz Saathoff wrote: Aus diesem Grund meinte ich, daß es eben nicht 'unmittelbar einsichtig' ist, daß diese Pointerarithmetik außerhalb allokiertem Bereich zu undefiniertem Verhalten führt, weil es eben auf vielen Maschinen klappt! Es muß aber nicht klappen! Wenn also ein Compilerhersteller für irgendeine Maschine aus dieser Einschränkung Optimierungsmöglichkeiten ableiten kann, die bei Nichtbeachtung zu Abstürzen führt, darf er das. Nicht mal unbedingt nur als Optimierung, sondern evtl. auch zur Sicherheit. Die Maschine meldet einen out-of-bounds pointer sofort, anstatt ihn vorerst zu ignorieren und dadurch einen Bug zu verschleiern. Es kann auch schlicht und einfach dazu führen, dass der Code "falsch" ausgeführt wird. Um mal das OP zu zitieren: Quote: char * buf = malloc(size); if (buf) { char *ptr = buf - 1; char end_buf = ptr + size; while ( ptr < end_buf && bedingung() ) [...] Ersetzen wir das mal durch einen größeren Typ 'struct Foo', meinetwegen 128 Bytes. Foo* buf = new Foo[size]; Foo* ptr = ptr - 1; Foo* end = ptr + size; while (ptr < end) ++ptr; Auf der Maschine, auf der ich gerade arbeite (ein DSP), liefert der erste Aufruf von malloc/new pro Programmlauf die Adresse 0x28 (oder soetwas in der Gegend, der Heap beginnt jedenfalls bei 0x20). 'ptr' enthielte dann die Adresse 0xFFFFFFA8, 'end' meinetwegen (bei size=10) 0x528. Die while-Schleife wird also nie betreten, weil ptr schon von Anfang an größer als end ist. Das dürfte das Beispiel sein, was Lutz meinte. Mit den guten alten DOS-Speichermodellen dürften sich weitere Effekte finden lassen. Da liefert 'farmalloc' ja auch gerne mal kleine Offsets. Stefan -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ (German) All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.