ÜBERSICHT

#include <stdlib.h>

---

void *malloc(size_t size);
void free(void *ptr);
void *calloc(size_t nmemb, size_t size);
void *realloc(void *ptr, size_t size);

BESCHREIBUNG

malloc() belegt size Byte und gibt einen Zeiger auf den belegten Speicherbereich zurück. Der Speicher wird nicht initialisiert. Falls size 0 ist, wird malloc() entweder NULL zurückgeben oder einen eindeutigen Zeigerwert, der später erfolgreich an free() übergeben werden kann.

free() gibt den Speicher frei, auf den ptr zeigt, welcher von einem früheren Aufruf von malloc(), calloc() oder realloc() belegt worden sein muss. Andernfalls oder wenn free(ptr) bereits aufgerufen wurde, ist das Verhalten nicht definiert. Wenn ptr NULL ist, wird keine Operation ausgeführt.

calloc() belegt Speicher für ein Array von nmemb Elementen von jeweils size Byte und gibt einen Zeiger auf den belegten Speicherbereich zurück. Der Speicher wird auf Null gesetzt. Falls nmemb oder size 0 ist, gibt calloc() entweder NULL zurück oder einen eindeutigen Zeigerwert, der später erfolgreich an free() übergeben werden kann.

realloc() ändert die Größe des Speicherblocks, auf den ptr zeigt, auf size Byte. Der Inhalt bleibt unverändert im Bereich vom Anfang des Speicherbereichs bis zum Minimum von alter und neuer Größe. Falls die neue Größe die alte überschreitet, wird der zusätzliche Speicher nicht initialisiert. Falls ptr gleich NULL ist, ist der Aufruf äquivalent zu malloc(size); falls die Größe gleich Null ist und ptr ist von NULL verschieden, ist der Aufruf äquivalent zu free(ptr). Wenn ptr nicht NULL ist, muss er von einem früheren Aufruf von malloc(), calloc() oder realloc() zurückgegeben worden sein. Falls der Bereich, auf den verwiesen wurde, verschoben wurde, wird free(ptr) aufgerufen.

RÜCKGABEWERT

Die Funktionen malloc() und calloc() liefern einen Zeiger auf den reservierten Speicher, der geeignet für jeden eingebauten Typ ausgerichtet ist. Tritt ein Fehler auf, geben diese Funktionen NULL zurück. NULL kann auch durch einen erfolgreichen Aufruf von malloc() mit einer size von Null oder durch einen erfolgreichen Aufruf von calloc() mit nmemb oder size gleich Null zurückgegeben werden.

Die Funktion free() gibt keinen Wert zurück.

Die Funktion realloc() gibt einen Zeiger auf den neu belegten Speicher zurück, welcher für jeden eingebauten Typ passend ausgerichtet ist und sich von ptr unterscheiden kann, oder NULL falls die Anforderung scheitert. Falls size gleich 0 war, wird entweder NULL oder ein für die Übergabe an free() geeigneter Zeiger zurückgegeben. Wenn realloc() scheitert, bleibt der ursprüngliche Block unverändert - er wird nicht freigegeben oder verändert.

FEHLER

calloc(), malloc() und realloc() können mit den follogenden Fehlern fehlschlagen:

ENOMEM

Speicher erschöpft. Möglicherweise erreichte die Anwendung die in getrlimit(2) beschriebene Grenze RLIMIT_AS oder RLIMIT_DATA.

ATTRIBUTE

Siehe attributes(7) für eine Erläuterung der in diesem Abschnitt verwandten Ausdrücke.

Schnittstelle	Attribut	Wert
malloc(), free(), calloc(), realloc()	Multithread-Fähigkeit	MT-Safe

KONFORM ZU

POSIX.1-2001, POSIX.1-2008, C89, C99.

ANMERKUNGEN

Standardmäßig verfolgt Linux eine optimistische Strategie bei der Speicherzuweisung. Das bedeutet nicht, dass der Speicher garantiert verfügbar ist, wenn malloc() einen von NULL verschiedenen Zeiger zurück gibt. Falls es sich herausstellt, dass das System über keinen freien Speicher verfügt, werden ein oder mehrere Prozesse vom »OOM Killer« beendet. Für weitere Informationen siehe die Beschreibung von /proc/sys/vm/overcommit_memory und /proc/sys/vm/oom_adj in proc(5) sowie die Linux-Kernel-Quelldatei Documentation/vm/overcommit-accounting.

Normalerweise stellt malloc() Speicher auf dem Heap bereit und passt je nach Bedarf die Größe des Heaps mittels sbrk(2) an. Bei der Zuweisung von Speicherblöcken größer als MMAP_THRESHOLD Bytes reserviert die Glibc-Implementierung von malloc() den Speicher als eine private anonyme Zuordnung mithilfe von mmap(2). MMAP_THRESHOLD ist standardmäßig 128 kB, kann aber mittels mallopt(3) angepasst werden. Reservierungen unter Verwendung von mmap(2) sind von der Ressourcenbeschränkung RLIMIT_DATA (siehe getrlimit(2)) nicht betroffen.

Um Verfälschungen in Multithread-Anwendungen zu vermeiden, werden intern Mutexe zum Schutz der Speicherverwaltungs-Datenstrukturen eingesetzt, die von diesen Funktionen genutzt werden. In einer Multithread-Anwendung, in denen Threads gleichzeitig Speicher zuweisen und freigeben, könnte es Zugangskonflikte für diese Mutexe geben. Um die Speicherzuweisung in Multithread-Anwendungen skalierbar zu bewältigen, erzeugt Glibc zusätzliche memory allocation arenas, wenn Mutex-Konflikte entdeckt wird. Jede Arena ist eine große Speicherregion, die intern vom System (mit brk(2) oder mmap(2)) zugeordnet und mit eigenen Mutexen verwaltet wird.

SUSv2 fordert von malloc(), calloc() und realloc() im Fehlerfall errno auf ENOMEM zu setzen. Glibc geht davon aus, dass das getan wurde (und die Glibc-Versionen dieser Routinen tun es). Wenn Sie eine private Implementierung von malloc verwenden, die errno nicht setzt, können bestimmte Bibliotheksroutinen ohne einen Grund in errno fehlschlagen.

Abstürze in malloc(), calloc(), realloc() oder free() haben nahezu immer einen Bezug zu einem beschädigten Heap, wie z.B. eine Nutzung von mehr als dem zugeordneten Bereich (overflowing) oder die doppelte Freigabe eines Zeigers.

Die malloc()-Implementierung kann über Umgebungsvariablen eingestellt werden. Für Details siehe mallopt(3).

KOLOPHON

Diese Seite ist Teil der Veröffentlichung 4.06 des Projekts Linux-man-pages. Eine Beschreibung des Projekts, Informationen, wie Fehler gemeldet werden können sowie die aktuelle Version dieser Seite finden sich unter https://www.kernel.org/doc/man-pages/.

ÜBERSETZUNG

Die deutsche Übersetzung dieser Handbuchseite wurde von Martin Eberhard Schauer <[email protected]> und Mario Blättermann <[email protected]> erstellt.

Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an <[email protected]>.