NOM¶

malloc, free, calloc, realloc, reallocarray — Allocation et libération de mémoire dynamique

BIBLIOTHÈQUE¶

Bibliothèque C standard (libc, -lc)

SYNOPSIS¶

#include <stdlib.h>

void *malloc(size_t taille);
void free(void *_Nullable p);
void *calloc(size_t n, size_t taille);
void *realloc(void *_Nullable p, size_t taille);
void *reallocarray(void *_Nullable p, size_t n, size_t taille);

reallocarray() :

    Depuis la glibc 2.29 :


        _DEFAULT_SOURCE


    glibc 2.28 et précédentes :


        _GNU_SOURCE

DESCRIPTION¶

malloc(n * taille);

realloc(p, n * taille);

VALEUR RENVOYÉE¶

Les fonctions malloc(), calloc(), realloc() et reallocarray() renvoient un pointeur vers la mémoire allouée qui est correctement alignée pour n'importe quel type dont la taille correspondra à la taille demandée ou sera inférieure à cette dernière. Si elles échouent, elles renvoient NULL et définissent errno pour indiquer l'erreur. Essayer d'allouer plus que PTRDIFF_MAX octets est considéré comme une erreur, car un objet de cette taille pourrait provoquer un dépassement lors d'une soustraction de pointeur ultérieure.

La fonction free() ne renvoie aucune valeur et préserve errno.

Les fonction realloc() et reallocarray() renvoient NULL si p est différent de NULL et si la taille demandée est égale à zéro, ce qui n'est pas considéré comme une erreur (consulter « Comportement non portable » pour les problèmes de portabilité). Dans le cas contraire, le pointeur renvoyé peut être identique à p si la zone mémoire n'a pas été déplacée (par exemple s'il y a assez de place pour l'étendre à son emplacement), ou peut être différent de p si la zone mémoire a été déplacée à une nouvelle adresse. Si ces fonctions échouent, le bloc mémoire originel reste intact ; il n'est ni libéré ni déplacé.

ERREURS¶

calloc(), malloc(), realloc() et reallocarray() peuvent échouer avec l'erreur suivante :

ENOMEM

Plus de mémoire. Il est possible que l'application ait atteint les limites RLIMIT_AS ou RLIMIT_DATA décrites dans getrlimit(2). Une autre raison pourrait être que le nombre de mappages créés par le processus appelant dépasse la limite spécifiée par /proc/sys/vm/max_map_count.

ATTRIBUTS¶

Pour une explication des termes utilisés dans cette section, consulter attributes(7).

NORMES¶

malloc()

free()

calloc()

realloc()

C23, POSIX.1-2024.

reallocarray()

POSIX.1-2024.

HISTORIQUE¶

malloc()

free()

calloc()

realloc()

POSIX.1-2001, C89.

reallocarray()

glibc 2.26. OpenBSD 5.6, FreeBSD 11.0.

Depuis la glibc 2.30, malloc() et les fonctions de la même famille refusent les tailles supérieures à PTRDIFF_MAX.

Depuis la glibc 2.33, free() préserve errno.

NOTES¶

Par défaut, Linux suit une stratégie d'allocation optimiste. Cela signifie que lorsque malloc() ne renvoie pas NULL, il n'y a aucune garantie que la mémoire soit véritablement disponible. S'il devait s'avérer que le système manque de mémoire, un ou plusieurs processus seraient tués par « OOM killer » (gestionnaire de mémoire). Pour plus d'informations, consultez la description de /proc/sys/vm/overcommit_memory et /proc/sys/vm/oom_adj dans proc(5), ainsi que le fichier Documentation/vm/overcommit-accounting.rst dans les sources du noyau Linux.

En général, malloc() alloue la mémoire depuis le tas, et ajuste la taille du tas en conséquence avec sbrk(2). Lorsque les blocs de mémoire alloués sont supérieurs à MMAP_THRESHOLD octets, l'implémentation de la glibc de malloc alloue la mémoire selon une projection anonyme privée avec mmap(2). MMAP_THRESHOLD vaut 128 ko par défaut et il est ajustable avec mallopt(3). Avant Linux 4.7, les allocations réalisées avec mmap(2) n’étaient pas affectées par la limitation de ressource RLIMIT_DATA ; depuis Linux 4.7, cette limite est aussi prise en compte pour les allocations faites avec mmap(2).

Pour éviter les corruptions d'applications multithread, les mutex sont utilisés en interne pour protéger les structures de données de gestion de mémoire utilisées dans ces fonctions. Dans une application multithread où les threads allouent et libèrent la mémoire en même temps, ces mutex risquent d'entrer en conflit. Pour gérer l'allocation de mémoire de façon évolutive dans les applications multithread, la glibc crée des domaines d'allocation mémoire si un conflit de mutex est détecté. Chaque domaine est un grand espace de mémoire qui est alloué en interne par le système (en utilisant brk(2) ou mmap(2)) et géré avec ses propres mutex.

Si votre programme utilise un allocateur de mémoire privé, il doit le faire en remplaçant malloc(), free(), calloc() et realloc(). Les fonctions de remplacement doivent implémenter les comportements de la glibc documentés, y compris la gestion de errno, les allocations de taille nulle et la surveillance des dépassements ; si ce n'est pas le cas, d'autres routines de la bibliothèque pourront planter ou fonctionner de manière incorrecte. Par exemple, si la fonction qui remplace free() ne préserve pas errno, des routines de la bibliothèque apparemment sans rapport pourront échouer sans indiquer de raison valable dans errno. Un allocateur de mémoire privé devra peut-être aussi remplacer d'autres fonctions de la glibc ; consulter « Remplacer malloc » dans le manuel de la glibc pour plus de détails.

L'échec d'un allocateur de mémoire est presque toujours le signe d'une corruption du tas, à l'instar d'un débordement de bloc mémoire alloué ou d'une double libération du même pointeur.

L'implémentation de malloc() est personnalisable à l'aide des variables d'environnement. Pour plus de précisions, consultez mallopt(3).

BOGUES¶

Les programmeurs s’attendent naturellement par induction à ce que realloc(p, size) soit cohérent avec free(p) et malloc(size), car c’est le comportement adopté dans le cas général. Ce comportement n’est pas explicitement imposé par POSIX.1-2024 ou C11, mais toutes les implémentations qui s’y conforment sont en accord avec cela.

L’implémentation de realloc() par la glibc n’est pas cohérente avec ce comportement et par voie de conséquence, il est dangereux d’utiliser realloc(p, 0) avec la glibc.

Un contournement évident pour la glibc consiste à utiliser realloc(p, size?size:1).

Le contournement pour la version de la glibc de reallocarray() — qui partage le même bogue — consisterait à utiliser reallocarray(p, n?n:1, size?size:1).

EXEMPLES¶

#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 taille);
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 taille)
{


    return reallocarray(NULL, n, taille);
}

VOIR AUSSI¶

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)

For details of the GNU C library implementation, see https://sourceware.org/glibc/wiki/MallocInternals.

TRADUCTION¶

La traduction française de cette page de manuel a été créée par Christophe Blaess <https://www.blaess.fr/christophe/>, Stéphan Rafin <stephan.rafin@laposte.net>, Thierry Vignaud <tvignaud@mandriva.com>, François Micaux, Alain Portal <aportal@univ-montp2.fr>, Jean-Philippe Guérard <fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-luc.coulon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas Huriaux <thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin Duneau <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis Barbier <barbier@debian.org>, David Prévot <david@tilapin.org>, Grégoire Scano <gregoire.scano@malloc.fr> et Lucien Gentis <lucien.gentis@waika9.com>

Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à debian-l10n-french@lists.debian.org.