Ja, richtig. Die interessantere Frage ist aber nicht wo die Ursache ist, sondern was genau dabei passiert. Da es eine lokale Variable auf dem Call Stack ist, wird dieser überschrieben und damit alle im Stack folgenden Rücksprungadressen, Funktionsparameter, etc. Kurz gesagt, Katastrophe. In diesem Fall ist es sogar noch schlimmer, da ohne Debugger das Programm an der Stelle der früher oder später resultierenden Zugriffsverletzung still beendet ("bla bla" wird nicht ausgegeben), ohne auf das Fehlverhalten mit einer entsprechenden Ausnahmebehandlung zu reagieren.Zitat von Mivey
Ursprünglich war es wie erwähnt eine Dateioperation, fread um genau zu sein. memset sollte wirklich nur dem Vorführungszweck dienen.
Da würden dir die C-Entwickler vermutlich etwas anderes sagen. Redundanz im Zeichen der Fehlerreduzierung entspricht zum Beispiel nicht der C-Philosophie.
Die Frage, ob man auf malloc verzichten sollte erinnert mich an die Frage, ob man auf goto verzichten sollte. Hierzu:
Besonders in C hat goto einen festen Platz und vereinfacht oft den Code, wie zum Beispiel in der Ausnahmebehandlung. Ähnlich verhält es sich mit malloc und calloc. Beide haben Vor- und Nachteile, die je nach Situation andere Gewichtung haben können. Verdammen ist ist in meinen Augen nie gut und schädlicher als fragliche Anwendung.
Ohne Code sind diese Resultate nicht wirklich repräsentativ. Man kann auf eine Weise messen und auf eine andere mit jeweils völlig unterschiedlichen Ergebnissen. Entscheidend wären beispielsweise, Granularität, Mittelwertbildung mehrerer Messwerte um Abweichungen durch Interrupts und ähnliches zu minimieren, Reduzierung auf die Messung der tatsächlichen Arbeit (free ist ein Störfaktor), usw.
Ich habe mal einige Messungen auf meinem Pentium D 2.8 Ghz gemacht und bei mir braucht malloc für 1 MB im Schnitt (10 Messungen hintereinander) etwa 12500 clock cycles (entspricht etwa 4.46 us bei 2.8 Ghz) und calloc etwa 13500 clock cycles (etwa 4.82 us). Damit ist calloc um 8% langsamer als malloc. Nicht viel, aber viel hat man hier auch nicht erwartet, denn Nullsetzung ist sehr billig und in heutigen Zeiten in der Regel SIMD-optimiert. Natürlich erhebe ich keinen Anspruch, dass auch meine Messungen 100%-ig repräsentativ und fehlerfrei sind. Jedenfalls gibt es einen Unterschied, der in manchen Situationen sogar größer sein kann und damit eventuell abgewogen werden könnte, wie zum Beispiel auf Systemen ohne SIMD, wenigen und kleinen Caches etc.
