BEZEICHNUNG

malloc, free, calloc, realloc, reallocarray - dynamischen Speicher belegen und freigeben

BIBLIOTHEK

Standard-C-Bibliothek (libc, -lc)

ÜBERSICHT

#include <stdlib.h>

void *malloc(size_t Größe);
void free(void *_Nullable z);
void *calloc(size_t n, size_t Größe);
void *realloc(void *_Nullable z, size_t Größe);
void *reallocarray(void *_Nullable z, size_t n, size_t Größe);

reallocarray():

    Seit Glibc 2.29:
        _DEFAULT_SOURCE
    Glibc 2.28 und älter:
        _GNU_SOURCE

BESCHREIBUNG

malloc(n * Größe);

realloc(z, n * Größe);

RÜCKGABEWERT

Die Funktionen malloc(), calloc(), realloc() und reallocarray() liefern einen Zeiger auf den reservierten Speicher, der geeignet für jeden Typ, der in die angeforderte Größe oder weniger passt, ausgerichtet ist. Tritt ein Fehler auf, geben diese Funktionen NULL zurück und setzen errno. Versuche, mehr als PTRDIFF_MAX byte zu belegen, wird als ein Fehler betrachtet, da ein Objekt dieser Größe bei späterer Zeigersubtraktion zu einem Überlauf führen könnte.

Die Funktion free() gibt keinen Wert zurück und erhält errno.

Die Funktionen realloc() und reallocarray() liefern NULL zurück, falls z nicht NULL ist und die angeforderte Größe Null ist; dies wird nicht als Fehler betrachtet. (Siehe »Nichtportables Verhalten« für Portabilitäts-Probleme.) Andernfalls kann der zurückgelieferte Zeiger zu z identisch sein, falls die Belegung nicht verschoben wurde (z.B. weil genug Platz vorhanden war, um die Belegung am Ort selbst zu vergrößern) oder sich von z unterscheiden, falls die Belegung an eine neue Adresse verschoben wurde. Wenn diese Funktionen scheitern, bleibt der ursprüngliche Block unverändert - er wird nicht freigegeben oder verschoben.

FEHLER

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

ENOMEM

Speicher erschöpft. Möglicherweise erreichte die Anwendung die in getrlimit(2) beschriebene Grenze RLIMIT_AS oder RLIMIT_DATA. Ein anderer Grund könnte sein, dass die Anzahl der durch den aufrufenden Prozess erstellten Mappings die durch /proc/sys/vm/max_map_count festgelegte Grenze überschritten hat.

ATTRIBUTE

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

STANDARDS

malloc()

free()

calloc()

realloc()

C23, POSIX.1-2024.

reallocarray()

POSIX.1-2024.

GESCHICHTE

malloc()

free()

calloc()

realloc()

POSIX.1-2001, C89.

reallocarray()

Glibc 2.26. OpenBSD 5.6, FreeBSD 11.0.

malloc() und verwandte Funktionen lehnen seit Glibc 2.30 Größen größer als PTRDIFF_MAX ab.

Seit Glibc 2.33 erhält free() errno.

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 getötet. 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.rst.

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() mithilfe von mmap(2) den Speicher als ein privates anonymes Mapping. MMAP_THRESHOLD ist standardmäßig 128 kB, kann aber mittels mallopt(3) angepasst werden. Vor Linux 4.7 waren Reservierungen unter Verwendung von mmap(2) von der Ressourcenbeschränkung RLIMIT_DATA nicht betroffen; seit Linux 4.7 wird diese Beschränkung auch bei Reservierungen mittels mmap(2) durchgesetzt.

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.

Falls Ihr Programm einen privaten Speicher-Zuordner verwendet, sollte dies so erfolgen, dass malloc(), free(), calloc() und realloc() ersetzt werden. Die Ersatzfunktionen müssen das dokumentierte Glibc-Verhalten implementieren, einschließlich der Handhabung von errno, Belegungen der Größe Null und der Prüfungen auf Überlauf; andernfalls könnten andere Bibliotheksroutinen abstürzen oder falsch funktionieren. Falls der Ersatz für free() beispielsweise errno nicht erhält, dann könnten Bibliotheksfunktionen, die scheinbar keinen Bezug dazu haben, fehlschlagen, ohne einen gültigen Grund in errno anzugeben. Private Speicher-Zuordner könnten es auch notwendig machen, andere Glibc-Funktionen zu ersetzen; siehe »Replacing malloc« im Handbuch der Glibc für Details.

Abstürze in Speicher-Zuordner 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).

FEHLER

Programmierer würden gemäß Induktion natürlicherweise erwarten, dass realloc(p, size) mit free(p) und malloc(size) konsistent ist, da dies das Verhalten in dem allgemeinen Falle ist. Dies wird von POSIX.1-2024 oder C11 nicht explizit verlangt, aber alle konformen Implementierungen sind damit konsistent.

Die Glibc-Implementierung von realloc() ist damit nicht konsistent und konsequenterweise ist es daher gefährlich, realloc(p, 0) in Glibc aufzurufen.

In Glibc kann dies trivial durch Aufruf von realloc(p, size?size:1) umgangen werden.

Die Vermeidung für reallocarray() in Glibc –das dem gleichen Fehler unterliegt– wäre reallocarray(p, n?n:1, size?size:1).

BEISPIELE

#include <err.h>
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define MALLOCARRAY(n, type)  ((type *) my_mallocarray(n, sizeof(type)))
#define MALLOC(type)          MALLOCARRAY(1, type)
static inline void *my_mallocarray(size_t n, size_t size);
int
main(void)
{
    char  *p;
    p = MALLOCARRAY(32, char);
    if (p == NULL)
        err(EXIT_FAILURE, "malloc");
    strlcpy(p, "foo", 32);
    puts(p);
}
static inline void *
my_mallocarray(size_t n, size_t size)
{
    return reallocarray(NULL, n, size);
}

SIEHE AUCH

valgrind(1), brk(2), mmap(2), alloca(3), malloc_get_state(3), malloc_info(3), malloc_trim(3), malloc_usable_size(3), mallopt(3), mcheck(3), mtrace(3), posix_memalign(3)

Für Details über die GNU-C-Bibliotheksimplementierung, siehe https://sourceware.org/glibc/wiki/MallocInternals.

ÜBERSETZUNG

Die deutsche Übersetzung dieser Handbuchseite wurde von Martin Eberhard Schauer <Martin.E.Schauer@gmx.de>, Mario Blättermann <mario.blaettermann@gmail.com> und Helge Kreutzmann <debian@helgefjell.de> 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 die Mailingliste der Übersetzer: debian-l10n-german@lists.debian.org.