Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (ANSI-Standard) » Adressenmanipulation

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: [ 1 ] > 2 <
010
18.05.2012, 20:39 Uhr
banshee




Zitat von 0xdeadbeef:
3D != der Länge 3.


Ach so, ich meinte nicht einen Vektor als Collection sondern wirklich im mathematischen Sinne, und da bedeuten 3 Elemente auch 3 Dimensionen, sofern ich mich jetzt nicht vollkommen irre.


Zitat von ao:
Dass du das machen kannst, heißt nicht, dass du es machen darfst. Das 4. Element existiert nicht, du greifst auf Speicher zu, der dir nicht gehört und der vielleicht vom Programm oder von der Speicherverwaltung oder von sonstwem für andere Dinge verwendet wird.

Im günstigen Fall bekommst du sofort eins auf die Finger (Access Violation), im ungünstigen Fall läuft das Programm erst mal eine Weile weiter und kracht später an ganz anderer Stelle.

Das sind äußerst fiese Fehler, die entscheidend zu dem schlechten Ruf beigetragen haben, den C und C++ in manchen Kreisen haben, und Programmierer tun gut daran, sich frühzeitig dafür zu sensibilisieren.


Und genau deshalb wäre es doch sinnvoll, das übergebene Argument kurz zu checken. Es ist ja nicht so, dass man dem Anwender unbedingt Absicht unterstellen müsste (obwohl ein Angreifer das potentiell ausnutzen könnte, um eben private Speicherbereiche auszulesen), aber wenn man in einem Riesenprojekt aus Versehen einen falschen Index angibt, dann -98328753 zurück kriegt, und die Anwendung in einem komplett anderen Modul crashed - viel Spaß beim debuggen
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
011
21.05.2012, 19:03 Uhr
Lensflare



für den konkreten Fall wäre wohl eine assertion am besten:


C++:
const T operator[] (unsigned int i) const {
    assert(i>=0 && i<3);
    return *(&x+i);
}




Zitat:

Es ist ja nicht so, dass man dem Anwender unbedingt Absicht unterstellen müsste(...)


Was meinst du damit?
Wenn der Anwender dazu aufgefordert würde, einen Index einzugeben, der dann direkt als Index für den Vektor verwendet wird, dann sollte man das natürlich checken. Unabhängig von debug/release.
Aber wenn der Anwender das Programm "hacken" will, indem er die kompilierte Datei oder den Arbeitsspeicher manipuliert, dann wird er sich wahrscheinlich auch nicht dadurch aufhalten lassen, dass der index geprüft wird.

Ich kann mir nicht vorstellen, dass beispielsweise Java Programme "sicherer" als C++ Programme sind, nur weil der array index dort geprüft wird.
Korrigiert mich bitte wenn ich falsch liege
--
Wenn das Gehirn so einfach wäre, dass wir es verstehen könnten, wären wir so einfach, dass wir es nicht verstehen könnten.
(Emerson Pugh Trost)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
012
22.05.2012, 09:28 Uhr
ao

(Operator)



Zitat von banshee:
Und genau deshalb wäre es doch sinnvoll, das übergebene Argument kurz zu checken. Es ist ja nicht so, dass man dem Anwender unbedingt Absicht unterstellen müsste (obwohl ein Angreifer das potentiell ausnutzen könnte, um eben private Speicherbereiche auszulesen), aber wenn man in einem Riesenprojekt aus Versehen einen falschen Index angibt, dann -98328753 zurück kriegt, und die Anwendung in einem komplett anderen Modul crashed - viel Spaß beim debuggen


So pauschal würde ich nicht sagen, dass das sinnvoll ist.

Es geht hier um ein Array-Template, eine primitive Wrapper-Klasse, die in erster Linie eins sein soll: Performant. Klassen wie diese werden hundertfach in größeren Programmen verwendet, und jede kleine Verschwendung, die man hier begeht, zählt deshalb hundertfach. Da läppert sich echt was zusammen.

Die traditionelle C-Denke ist, dass jeder Programmierer verantwortlich ist für das, was er tut. Die Verantwortung einfach weiterschieben und sagen "die Bibliothek muss prüfen, was ich mache" - das gibts in diesem Modell nicht.

Für interne Funktionen, Array-Wrapper und so ein Zeugs ist das der richtige Ansatz, denn er hält Programme klein und schnell. Für Fehler während der Entwicklungsphase gibts Assertions, die beim Release-Compile rausfallen, die wären hier eine Überlegung wert. Aber grundsätzlich den Index prüfen? Nein, das wäre meiner Meinung nach mit Kanonen auf Spatzen geschossen. Weil es im fertig ausgetesteten Programm nicht mehr zu diesen Fehlern kommt (*), muss in der Release-Fassung auch keine Prüfung mehr stattfinden.

(*) vorausgesetzt, man hat sorgfältig genug analysiert und getestet, um das sagen zu können.

Für Funktionen auf API-Ebene gilt das natürlich nicht. Die müssen sich selbstverständlich gegen Aufruffehler schützen, und wenn böswillige Angriffe zu erwarten sind, dann besonders. Das muss die API-Schicht aber selbst übernehmen und kann nicht davon ausgehen, dass sie es einfach nach unten delegieren kann, und irgendwer wird ihr das schon abnehmen.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: [ 1 ] > 2 <     [ C / C++ (ANSI-Standard) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: