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

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.

asc

Artchi schrieb:

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

Schlechtes Beispiel. Ich bekomme unter dem MSVC 2008 beispielsweise KEINE Exception, jedenfalls nicht mittels Indexoperators (Nur bei der at-Methode ist die Indexprüfung garantiert). Und das Beispiel steht dazu bereits im 4ten Post des Threads.

traceman

Danke ich habs schon verstanden. Anfangs habe ich Visual Studio verdächtigt weil ich nicht glauben konnte das es ein generelles c problem ist, aber auch weil ich noch nie probleme mit sowas hatte.

Artchi

asc schrieb:

Artchi schrieb:

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

Schlechtes Beispiel. Ich bekomme unter dem MSVC 2008 beispielsweise KEINE Exception, jedenfalls nicht mittels Indexoperators (Nur bei der at-Methode ist die Indexprüfung garantiert). Und das Beispiel steht dazu bereits im 4ten Post des Threads.

Ja, in MSVC2008 wurde glaube ich wieder dieses _SECURE_SCL-Makro von MS auf 0 gesetzt (nachdem sich alle bei MSVC2005 aufgeregt haben). Das mußt du wieder einschalten... dann ist auch der Index-Op bei vector sicher!

Nexus

Artchi schrieb:

Ja, in MSVC2008 wurde glaube ich wieder dieses _SECURE_SCL-Makro von MS auf 0 gesetzt (nachdem sich alle bei MSVC2005 aufgeregt haben). Das mußt du wieder einschalten... dann ist auch der Index-Op bei vector sicher!

Es ist trotzdem kein Standard. Dass es bei einigen Compilern unter der Bedingung läuft, dass gewisse Makros so oder so definiert sind, tut nichts zur Sache. Man sollte bei operator[] nicht von einer Exception ausgehen, wenn man portabel bleiben will. Genau für diese Fälle wurde ja at() konzipiert!

Bashar

Artchi schrieb:

Es ist doch eigentlich eine ganz einfache Erklärung:
[...]
Beim Kollegen kann Auswirkung stattfinden, weil an test[15] wahrscheinlich Code liegt. Bei einem selber aber nichts bedeutendes liegt.

Sehr, sehr unwahrscheinlich, dass 5 Bytes oberhalb einer beliebigen lokalen Variable Code liegt! Der würde ja beim nächsten Funktionsaufruf schon überschrieben werden. Noch viel unwahrscheinlicher, dass so ein Zugriff dann die Fehlermeldung "Stack Overflow" verursacht. Du machst es dir mit der Erklärung wohl etwas zu einfach.

Dass der Code undefiniertes Verhalten hat, hatten wir schon auf Seite 1 geklärt. Es bleibt einzig und allein das konkret beobachtete Verhalten zu erklären. Beim Debuggen ist das ziemlich nütztlich, um bestimmte Effekte beurteilen zu können. Normalerweise baut man die Fehler ja nicht mit Absicht ein, um sich dann zu wundern ...

asc

traceman schrieb:

...weil ich nicht glauben konnte das es ein generelles c problem ist...

C und C++ sind im Gegensatz zu vielen anderen Sprachen eher auf die Performance als auf die Sicherheit orientiert. Wieso sollte bei einem Schleifendurchlauf bei jedem einzelnen Arrayzugriff eine Indexprüfung erfolgen, wenn ich selbst sicherstelle das ich den Index nicht überschreite?

Simon2

traceman schrieb:

...weil ich nicht glauben konnte das es ein generelles c problem ist...

Ist es auch nicht.

Es ist auch kein "Pascal-Problem", wenn ich "+" schreibe, wo ich eine Subtraktion erwarte.;)

Gruß,

Simon2.

Artchi

Nexus schrieb:

Artchi schrieb:

Ja, in MSVC2008 wurde glaube ich wieder dieses _SECURE_SCL-Makro von MS auf 0 gesetzt (nachdem sich alle bei MSVC2005 aufgeregt haben). Das mußt du wieder einschalten... dann ist auch der Index-Op bei vector sicher!

Es ist trotzdem kein Standard. Dass es bei einigen Compilern unter der Bedingung läuft, dass gewisse Makros so oder so definiert sind, tut nichts zur Sache. Man sollte bei operator[] nicht von einer Exception ausgehen, wenn man portabel bleiben will. Genau für diese Fälle wurde ja at() konzipiert!

Bla bla! Undefiniert heißt aber nunmal auch, das eine Exception fliegen darf und ein Hersteller den Index-Op sicher machen darf. Es ist nichts standard-unkonform, was da MS gemacht hat.

tntnet

Artchi schrieb:

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.

Das selbe kannst Du doch mit folgendem erreichen:

throw std::out_of_range("hey - da ist ein Index ausserhalb des zulaessigne Bereiches");

Da brauchst Du noch nicht mal ein vector oder Array. Da bekommst Du doch garantiert die Exception :D. Und das geht mit jedem C++-Compiler.

asc

Artchi schrieb:

Bla bla! Undefiniert heißt aber nunmal auch, das eine Exception fliegen darf und ein Hersteller den Index-Op sicher machen darf. Es ist nichts standard-unkonform, was da MS gemacht hat.

Nein, aber warum nicht die Variante wählen die GARANTIERT eine Indexprüfung macht, und nicht von irgendwelchen Compilern abhängig ist. Daher: die at-Methode verwenden wenn man wirklich sichergehen will das bei einer Indexüberschreitung eine Exception fliegt, und nicht darauf hoffen das der Indexoperator dies macht (und der muss, wie schon häufig geschrieben dies nicht tun, und macht dies beispielsweise von Haus auch nicht unter MSVC 2008).

Nexus

Artchi schrieb:

Bla bla! Undefiniert heißt aber nunmal auch, das eine Exception fliegen darf und ein Hersteller den Index-Op sicher machen darf. Es ist nichts standard-unkonform, was da MS gemacht hat.

Was Blabla? Ich sagte nur, dass der Standard nicht garantiert, dass bei operator[] eine Exception fliegt. Und ich finde es nicht gut, dass du empfiehlst, sich trotzdem darauf zu verlassen. Gerade wenn man eine Alternative wie at() hat, die unter allen Umständen eine std::out_of_range wirft.

Simon2

Artchi schrieb:

...Bla bla!...

Ich habe noch nie erlebt, dass diese Äußerung eine Diskussion positiv vorangebracht hätte...

Gruß,

Simon2.

hustbaer

Artchi schrieb:

asc schrieb:

Artchi schrieb:

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

Schlechtes Beispiel. Ich bekomme unter dem MSVC 2008 beispielsweise KEINE Exception, jedenfalls nicht mittels Indexoperators (Nur bei der at-Methode ist die Indexprüfung garantiert). Und das Beispiel steht dazu bereits im 4ten Post des Threads.

Ja, in MSVC2008 wurde glaube ich wieder dieses _SECURE_SCL-Makro von MS auf 0 gesetzt (nachdem sich alle bei MSVC2005 aufgeregt haben). Das mußt du wieder einschalten... dann ist auch der Index-Op bei vector sicher!

So what?

asc

hustbaer schrieb:

Artchi schrieb:

Ja, in MSVC2008 wurde glaube ich wieder dieses _SECURE_SCL-Makro von MS auf 0 gesetzt (nachdem sich alle bei MSVC2005 aufgeregt haben). Das mußt du wieder einschalten... dann ist auch der Index-Op bei vector sicher!

So what?

1. Hat man dann wieder Compilerabhängigen Code (finde zumindest ich unschön)
2. Finde ich es wesentlich besser wenn man bewusst zwischen einer garantierten Indexüberprüfung und einer voraussichtlich guten Performance wählen kann (Ich hatte schon ein paarmal Code wo sich _SECURE_SCL merkbar negativ ausgewirkt hat).

Mir persönlich wäre es sogar lieber wenn im Standard garantiert wäre das [] niemals prüft und at immer (Oder das die Überprüfung wenigstens an ein Compilerunabhängiges Makro etc. gepackt wird).

Bashar

asc schrieb:

Mir persönlich wäre es sogar lieber wenn im Standard garantiert wäre das [] niemals prüft

Das kann ja gar nicht gehen, so eine Mechanik gibts im Standard nicht.

Macht auch keinen Sinn: Die Überprüfung bei [] ist analog zu assert zu sehen. Das hat man in der Entwicklung drin und im Release nicht mehr. at dagegen scheint mir in jeder Hinsicht nutzlos zu sein.

hustbaer

asc schrieb:

hustbaer schrieb:

Artchi schrieb:

Ja, in MSVC2008 wurde glaube ich wieder dieses _SECURE_SCL-Makro von MS auf 0 gesetzt (nachdem sich alle bei MSVC2005 aufgeregt haben). Das mußt du wieder einschalten... dann ist auch der Index-Op bei vector sicher!

So what?

1. Hat man dann wieder Compilerabhängigen Code (finde zumindest ich unschön)
2. Finde ich es wesentlich besser wenn man bewusst zwischen einer garantierten Indexüberprüfung und einer voraussichtlich guten Performance wählen kann (Ich hatte schon ein paarmal Code wo sich _SECURE_SCL merkbar negativ ausgewirkt hat).

Mir persönlich wäre es sogar lieber wenn im Standard garantiert wäre das [] niemals prüft und at immer (Oder das die Überprüfung wenigstens an ein Compilerunabhängiges Makro etc. gepackt wird).

Ich wollte mit "so what" die Relevanz der Aussage von Artchi in Frage stellen.
Also wenn ich dich richtig verstehe ganz in deinem Sinne.

general bacardi

traceman schrieb:

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

unsigned char test[10];

#define IDX 15
  assert (IDX < sizeof(test));

  test[IDX] = 3;

Den Fehler bekommst du nicht beim kompilieren aber beim starten

Assertion failed: IDX < sizeof(test),......