Unterschied zwischen malloc und calloc?

Question

Was ist der Unterschied zwischen:

ptr = malloc (MAXELEMS * sizeof(char *));

oder:

ptr = calloc (MAXELEMS, sizeof(char*));

Wann ist es eine gute Idee, calloc statt malloc zu verwenden oder umgekehrt?

Answer 1

calloc() gibt Ihnen einen null-initialisierten Puffer, während malloc() lässt den Speicher uninitialisiert.

Bei großen Zuweisungen werden die meisten calloc Implementierungen unter gängigen Betriebssystemen erhalten vom Betriebssystem bekannte Nullseiten (z. B. über POSIX mmap(MAP_ANONYMOUS) oder Windows VirtualAlloc ), so dass sie nicht in den User-Space geschrieben werden müssen. So wird die normale malloc holt auch mehr Seiten aus dem Betriebssystem; calloc nutzt einfach die Garantie des Betriebssystems.

Dies bedeutet calloc Speicher kann immer noch "sauber" und "lazily-allocated" sein, und "copy-on-write" auf eine systemweit gemeinsam genutzte physische Seite mit Nullen abgebildet werden. (Unter der Annahme eines Systems mit virtuellem Speicher.)

Einige Compiler können sogar malloc + memset(0) in calloc für Sie optimieren, aber Sie sollten calloc explizit verwenden, wenn Sie den Speicher als 0 .

Wenn Sie den Speicher vor dem Schreiben nicht mehr lesen wollen, verwenden Sie malloc so dass es Ihnen (möglicherweise) schmutzigen Speicher aus seiner internen freien Liste geben kann, anstatt neue Seiten vom Betriebssystem zu bekommen. (Oder anstatt einen Speicherblock in der freien Liste für eine kleine Zuweisung auf Null zu setzen).

---

Eingebettete Implementierungen von calloc kann es überlassen calloc selbst auf Null setzen, wenn kein Betriebssystem vorhanden ist oder es sich nicht um ein ausgefallenes Mehrbenutzer-Betriebssystem handelt, das Seiten auf Null setzt, um Informationslecks zwischen Prozessen zu verhindern.

Unter Embedded Linux könnte malloc mmap(MAP_UNINITIALIZED|MAP_ANONYMOUS) die nur für einige eingebettete Kernel aktiviert ist, weil sie auf einem Mehrbenutzersystem unsicher ist.

Answer 2

Ein weniger bekannter Unterschied ist, dass in Betriebssystemen mit optimistischer Speicherzuweisung, wie Linux, der Zeiger, der von malloc wird nicht durch echten Speicher unterstützt, bis das Programm ihn tatsächlich berührt.

calloc den Speicher tatsächlich berührt (es schreibt Nullen darauf) und so können Sie sicher sein, dass das Betriebssystem die Zuweisung mit tatsächlichem RAM (oder Swap) unterstützt. Dies ist auch der Grund, warum es langsamer ist als malloc (es muss nicht nur Nullen schreiben, sondern das Betriebssystem muss auch einen geeigneten Speicherbereich finden, indem es möglicherweise andere Prozesse auslagert)

Siehe zum Beispiel diese SO-Frage für weitere Diskussionen über das Verhalten von malloc

Answer 3

Ein oft übersehener Vorteil von calloc ist, dass es (konforme Implementierungen) zum Schutz vor Integer-Überlauf-Schwachstellen beitragen wird. Vergleichen Sie:

size_t count = get_int32(file);
struct foo *bar = malloc(count * sizeof *bar);

vs.

size_t count = get_int32(file);
struct foo *bar = calloc(count, sizeof *bar);

Ersteres könnte zu einer winzigen Zuweisung und anschließenden Pufferüberläufen führen, wenn count größer ist als SIZE_MAX/sizeof *bar . Letzteres wird in diesem Fall automatisch fehlschlagen, da ein so großes Objekt nicht erstellt werden kann.

Natürlich müssen Sie auf nicht konforme Implementierungen achten, die die Möglichkeit eines Überlaufs einfach ignorieren... Wenn dies auf den Plattformen, auf die Sie abzielen, ein Problem darstellt, müssen Sie ohnehin einen manuellen Test auf Überlauf durchführen.

Answer 4

Die Dokumentation macht die calloc 似る malloc die lediglich eine Null-Initialisierung des Speichers vornimmt; dies ist nicht der Hauptunterschied! Die Idee von calloc ist die Abstraktion der Copy-on-Write-Semantik für die Speicherzuweisung. Wenn Sie Speicher zuweisen mit calloc alle auf dieselbe physische Seite abgebildet werden, die auf Null initialisiert ist. Wenn eine der Seiten des zugewiesenen Speichers in eine physische Seite geschrieben wird, wird diese zugewiesen. Dies wird häufig verwendet, um HUGE Hash-Tabellen zu erstellen, da die leeren Teile des Hash nicht durch zusätzlichen Speicher (Seiten) gesichert sind; sie verweisen einfach auf die einzige null-initialisierte Seite, die sogar zwischen Prozessen geteilt werden kann.

Jedes Schreiben auf eine virtuelle Adresse wird einer Seite zugeordnet, wenn diese Seite die Null-Seite ist, wird eine andere physische Seite zugewiesen, die Null-Seite wird dorthin kopiert und der Kontrollfluss wird an den Client-Prozess zurückgegeben. Dies funktioniert auf dieselbe Art und Weise wie speicherzugeordnete Dateien, virtueller Speicher usw es wird Paging verwendet.

Hier ist eine Optimierungsgeschichte zum Thema: http://blogs.fau.de/hager/2007/05/08/benchmarking-fun-with-calloc-and-zero-pages/

Answer 5

Es gibt keinen Unterschied in der Größe des zugewiesenen Speicherblocks. calloc füllt den Speicherblock einfach mit dem physischen Muster der Null-Bits. In der Praxis wird oft davon ausgegangen, dass die Objekte im Speicherblock, der mit calloc haben einen Anfangswert, als ob sie mit einem Literal initialisiert würden 0 , d.h. ganze Zahlen sollten den Wert von 0 Gleitkomma-Variablen - Wert von 0.0 , Zeiger - der entsprechende Null-Zeiger-Wert usw.

Vom pedantischen Standpunkt aus betrachtet, calloc (sowie memset(..., 0, ...) ) ist nur gewährleistet, dass Objekte des Typs unsigned char . Für alles andere wird nicht garantiert, dass es ordnungsgemäß initialisiert ist, und es kann so genannte Trap-Darstellung was zu undefiniertem Verhalten führt. Mit anderen Worten, für jeden anderen Typ als unsigned char das oben erwähnte Muster mit nur Null-Bits könnte einen illegalen Wert darstellen, Trap-Darstellung.

Später, in einer der technischen Korrekturen zum C99-Standard, wurde das Verhalten für alle Integer-Typen definiert (was Sinn macht). D.h. formal kann man in der aktuellen Sprache C nur Integer-Typen initialisieren mit calloc (und memset(..., 0, ...) ). Die Verwendung zur Initialisierung von etwas anderem führt in der Regel zu undefiniertem Verhalten aus der Sicht der Sprache C.

In der Praxis, calloc funktioniert, wie wir alle wissen :), aber ob Sie es verwenden möchten (in Anbetracht der oben genannten Punkte), liegt an Ihnen. Ich persönlich ziehe es vor, es komplett zu vermeiden und verwende malloc und führe stattdessen meine eigene Initialisierung durch.

Ein weiteres wichtiges Detail ist schließlich, dass calloc ist erforderlich, um die endgültige Blockgröße zu berechnen intern durch Multiplikation der Elementgröße mit der Anzahl der Elemente. Dabei wird, calloc muss auf einen möglichen arithmetischen Überlauf achten. Er führt zu einer erfolglosen Zuweisung (Null-Zeiger), wenn die angeforderte Blockgröße nicht korrekt berechnet werden kann. Inzwischen hat Ihr malloc Version unternimmt keinen Versuch, auf Überlauf zu achten. Es wird eine "unvorhersehbare" Menge an Speicher zugewiesen, falls ein Überlauf auftritt.