Zugriff auf nicht existierendes Element in einem Array VS2003 Kein Fehler?

traceman

Hallo Leute,

ich habe folgendes Problem in Visual Studio 2003.net. Folgender Code sollte doch einen Fehler generieren:

unsigned char test[10];
test[15] = 3;

Mein Visual Studio akzeptiert aber die Zuweisung!! Weiss jemand was ich in VS einstellen muss damit hier wirklich ein Fehler ausgeworfen wird?

Gruss

bgdnoy

As designed.
Siehe http://de.wikipedia.org/wiki/Pufferüberlauf

Bashar

traceman schrieb:

Folgender Code sollte doch einen Fehler generieren:

Nein, das Verhalten dieses Codes ist undefiniert. Willkommen in C++.

asc

traceman schrieb:

Folgender Code sollte doch einen Fehler generieren:

Wie die anderen schon geschrieben haben, ist dies unmöglich. C++ fordert eine gewisse Disziplin was die Programmierung angeht, dafür "bezahlt" man nur für das was man einsetzt.

Eine Alternative sind die Standardcontainer (Speziell std::vector und std::tr1::array, letzteres musst du aber unter VC2003 nachrüsten [z.B. über Boost] um in den Genuss zu kommen).

So bietet der vector beispielsweise einmal den Indexoperator [] und die Methode "at" an, um auf ein Element zuzugreifen. Ersterer muss keine Bereichsprüfungen durchführen (wobei dies der Standard auch nicht verbietet, in der Regel wird hier aber die performante [ungeprüfte] Variante gewählt), "at" wiederum prüft auf Indexüberschreitung und wirft in diesem Fall eine Exception (std::out_of_range).

#include <vector>

int main()
{
  std::vector<int> test(10, 0);
  test.at(15) = 12; // Liefert eine Exception bei Indexüberschreitung
  // test[15] = 12; => Kann, aber muss keine Exception werfen
}

traceman

Wieso gibts dann bei einem kollegen der die selbe umgebung hat mit dem selben programm eine exception: stack overflow?

MFK

traceman schrieb:

Wieso gibts dann bei einem kollegen der die selbe umgebung hat mit dem selben programm eine exception: stack overflow?

Weil das Verhalten undefiniert ist. Du kannst dich nicht darauf verlassen, dass etwas bestimmtes passiert.

Bashar

Das musst du schon deinen Compiler fragen. Im Debug-Modus übersetzt?

asc

traceman schrieb:

Wieso gibts dann bei einem kollegen der die selbe umgebung hat mit dem selben programm eine exception: stack overflow?

...davon abgesehen das es sich hierbei nicht um eine Exception im C++ Sinne handelt...

hustbaer

@asc: selbst eine Exception im C++ Sinne darf fliegen, da das Verhalten ja undefiniert ist
(Und es gibt ja auch einige Compiler/Plattformen die solche Fehler in C++ Exceptions "übersetzen" können - MSVC z.B.)

Bashar schrieb:

Willkommen in C++.

Genau

traceman

Also ich hab mal ein ganz neues Projekt aufgemacht (kein c++!!) dann im Debugmodus gestartet und nichts passiert..ob es eine Exception ist oder nicht ist mir jetzt zunächst mal egal er soll mir einen Fehler anzeigen! Wie gesagt ich benutze den Standard Compiler der mit dem Visual Studio 2003.net mitgeliefert wird.

// tt.cpp : Definiert den Einstiegspunkt für die Konsolenanwendung.
//

#include "stdafx.h"

int _tmain(int argc, _TCHAR* argv[])
{
	unsigned char test[10];

	test[15] = 9;

	return 0;
}

Nochmal: Wieso kommt bei einem Kollegen eine Fehlermeldung aber bei mir nicht? Unlösbares Problem?

theta

oje... bist Du schwer von Begriff?

asc

traceman schrieb:

Also ich hab mal ein ganz neues Projekt aufgemacht dann im Debugmodus gestartet und nichts passiert...
Nochmal: Wieso kommt bei einem Kollegen eine Fehlermeldung aber bei mir nicht?

Du liest also entweder die Antworten nicht, oder ignorierst sie. Das Verhalten bei einer Indexüberschreitung eines C-Arrays ist und bleibt undefiniert. Greif zu den Containern der C++ Standardbibliothek, und dort zu den geprüften aufrufen wenn du ein anderes Verhalten haben willst! (Nochmal der Verweis auf std::vector/std::tr1::array und die "at"-Methode).

Undefiniert ist und bleibt undefiniert!

Bashar

theta schrieb:

oje... bist Du schwer von Begriff?

Muss das sein?

Das Verhalten ist zwar nicht definiert, das heißt aber nicht, dass das Verhalten bei einem bestimmten Compiler vollkommen nichtdeterministisch ist. Der generiert ja irgendwelchen Maschinencode dafür, und die Frage, warums beim Kollegen kracht und hier nicht, ist auf jeden Fall berechtigt. Nur kann man die leider nicht so einfach beantworten. Dazu müsste man die genaue Fehlermeldung erstmal kennen. Man müsste vielleicht den Assemblercode mal im Vergleich sehen, ob es doch an irgendwelchen Einstellungen liegt. Compilerversion? Und so weiter, das aus der hohlen Hand zu beantworten ist nicht so einfach.

theta

Bashar schrieb:

theta schrieb:

oje... bist Du schwer von Begriff?

Muss das sein?

Nein, muss nicht sein.

traceman

ok ich werde mir noch mal die fehlermeldung vom kollegen genauer anschauen..

tntnet

Bashar schrieb:

theta schrieb:

oje... bist Du schwer von Begriff?

Muss das sein?

Das Verhalten ist zwar nicht definiert, das heißt aber nicht, dass das Verhalten bei einem bestimmten Compiler vollkommen nichtdeterministisch ist. Der generiert ja irgendwelchen Maschinencode dafür, und die Frage, warums beim Kollegen kracht und hier nicht, ist auf jeden Fall berechtigt. Nur kann man die leider nicht so einfach beantworten. Dazu müsste man die genaue Fehlermeldung erstmal kennen. Man müsste vielleicht den Assemblercode mal im Vergleich sehen, ob es doch an irgendwelchen Einstellungen liegt. Compilerversion? Und so weiter, das aus der hohlen Hand zu beantworten ist nicht so einfach.

Es ist doch möglicherweise nichtdeterministisch. Wenn ich auf Speicher zugreife, welcher mir nicht gehört, dann könnte der Speicher entweder zugreifbar sein oder nicht. Das ist nicht nur vom Compiler sondern auch vom Betriebssystem abhängig. Denkbar wäre sogar eine Situation, dass das Programm sich auf dem selben Rechner unterschiedlich verhält, je nachdem, welche Programme gerade laufen oder gerade gelaufen sind. Daher sollte sich jede weitere Nachforschung erübrigen.

Simon2

traceman schrieb:

ok ich werde mir noch mal die fehlermeldung vom kollegen genauer anschauen..

Und was soll das bringen?

Sorry, aber Dein Problem liegt weder in Deinem Code noch in dem Deines Kollegen ... und auch nicht in Deinen oder seinen Fehlermeldungen.

DU ERWARTEST DAS FALSCHE!!!

Oder ganz kurz:

Compiler => recht
Du => unrecht

Gruß,

Simon2.

Keithy

vielleicht kann jmnd versuchen ihm das so zu erklären, dass ER es versteht.

meine idee wäre:

Die Zuweisung "kann" so funktionieren, aber evlt steht an der stelle im Speicher schon was, und es kommt deswegen zu einem "stack overflow ?

geht das in die richtige richtung?

hustbaer

Keithy schrieb:

vielleicht kann jmnd versuchen ihm das so zu erklären, dass ER es versteht.

das bezweifle ich.

traceman

hustbaer schrieb:

"Let there be Licht..."

nur kompetente Leute hier..das muss man schon sagen

Artchi

Es ist doch eigentlich eine ganz einfache Erklärung:

unsigned char test[10];
test[15] = 3;

Bei der zweiten Zeile bzw. bei test[X] findet keine Überprüfung statt, ob der Array-Index gültig ist.

Bei der Zuweisung der 3 auf test[15] wird Speicher manipuliert. Und zwar illegal.
Aber das kann und muß keine Auswirkung haben. Beim Kollegen kann Auswirkung stattfinden, weil an test[15] wahrscheinlich Code liegt. Bei einem selber aber nichts bedeutendes liegt.

Es gibt doch eigentlich eine einfach Lösung: keine C-Arrays verwenden!
Sondern std::tr1::array oder std::vector . Beispiel:

vector<unsigned char> test(10);
test[15] = 3; // C++-Exception beim MSVC 2005! genauer gesagt std::out_of_range

Der MSVC2008 SP1 müsste sogar beim std::tr1:array eine Exception werfen... wenn ich mich nicht täusche.