Hilfe! Constructor macht nicht was er soll!

life

Vielleichst schreibste im Array (f_Light) über deinen Speicherbereich raus und damit in f_Texturing rein. Arraygröße von f_Light also vielleicht nur 6 und nicht 7?

Du hast recht. Das hab ich gar nicht gesehn! Aber wieso meckert mir das der Kompiler nicht an!

Ach ich ahne es schon: C/C++ is nunmal nicht typsicher. Wenn C/C++ das wäre, währe die Sprache richtig gut - und unsere Betriebssysteme um einiges Sicherer (Buffer-Overflows ade) *träum*

Danke

MFK

Anfänger06 schrieb:

Ach ich ahne es schon: C/C++ is nunmal nicht typsicher.

Das hat mit Typsicherheit nichts zu tun.

Wenn C/C++ das wäre, währe die Sprache richtig gut - und unsere Betriebssysteme um einiges Sicherer (Buffer-Overflows ade) *träum*

Man kann C++ so benutzen, dass so etwas nicht passieren kann. Es liegt eigentlich nur an dir.

Wenn stillschweigend Arraygrenzen überschritten werden ist das Typsicher? Also ich weiß nicht. Aber wieso meckert da der Compiler net? (GCC)

Ganz einfach eine Überprüfung sieht der Standard nicht vor. Wenn man es wollte, müsste man auch zur Laufzeit prüfen. Genau das will man in C++ vermeiden. An Stellen bei denen man es braucht kann man es selbst implementieren oder z.B. std::vector::at() verwenden, der schmeisst eine out-of-range exception.

Aber sowas könnte doch zur Compilezeit schon entdeckt werden.

MFK

Anfänger06 schrieb:

Wenn stillschweigend Arraygrenzen überschritten werden ist das Typsicher?

Wenn du ohne Gurt mit dem Auto fährst, ist das Safer Sex?
Das hat mit Typsicherheit nichts zu tun.

Anfänger06 schrieb:

Aber wieso meckert da der Compiler net? (GCC)

compiler(r) schrieb:

Aber sowas könnte doch zur Compilezeit schon entdeckt werden.

Man könnte argumentieren, dass die primäre Aufgabe eines Compilers die ist, das Programm zu übersetzen, nicht Fehler darin zu entdecken. Es gibt durchaus Erweiterungen bei einigen Compilern, bei denen die Abwesenheit dieser Prüfung bewusst ausgenutzt wird. Die WinAPI z.B. ist voll von Strukturen, die am Ende ein Array mit einem Element haben, das für Daten variabler Länge benutzt wird.

Konfusius

compiler(r) schrieb:

Aber sowas könnte doch zur Compilezeit schon entdeckt werden.

es könnte, aber das ist in c/c++ nicht wünschenswert. viele c-programmiere machen zb folgendes:

struct node
{
  struct node *next;
  unsigned size;
  char data[1];
} *n;

n=malloc(sizeof(struct node)-1+100);
n->size=100;

da wäre eine überlaufprüfung ärgerlich.

KFlash

Die WinAPI ist nicht unbedingt ein gutes Beispiel für sichere Programmierung. Ich will jatzt nicht auf MS rumhacken, teilweise können die auch gar nix dafür.

C hat mit funktionen wie strcpy() das gesamte sicherheitskonzept von MS unterhöhlt. Bufferoverflows sind damit vorprogrammiert. Unser Prof. hat uns in der Uni mal aufgezeigt wie sowas zu stande kommt. Und das läßt vermuten, dass solange Windows (und somit auch Unix das auf der selben Sprache basiert) nicht komplett neu geschrieben wird, Bufferoverfloas, niemals vermieden werden können. Die Sicherheit fängt da bei der Sprache an. Mit einer Typsicheren sprache die overflows von arrays einfach nicht erlaubt und entsprechend streng ist macht zwar dem eingefleischten C-Programmierer die Arbeit weniger spass, aber dem Hacker am anderen Ende gehts genauso.

PeterTheMaster

der compiler koennte nur an sehr wenigen stellen ein ueberschreiten der arraygrenzen feststellen, naemlich da, wo ueber ein zahlenliteral indiziert wird. ueberall anders muesste jeder moegliche programmablauf durchgerechnet werden, was nicht sinnvoll ist.

das mit dem "bufferoverflows koennen mit so einer sprache niemals vermieden werden" ist unsinn. man muss beim programmieren nur wissen, was man tut. etwa das array in eine klasse stecken und bei jedem zugriff die grenzen ueberpruefen oder aehnliches.