malloc(3) Library Functions Manual malloc(3) NOM malloc, free, calloc, realloc, reallocarray -- Allocation et liberation de memoire dynamique BIBLIOTHEQUE Bibliotheque C standard (libc, -lc) SYNOPSIS #include 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); Exigences de macros de test de fonctionnalites pour la glibc (consulter feature_test_macros(7)) : reallocarray() : Depuis la glibc 2.29 : _DEFAULT_SOURCE glibc 2.28 et precedentes : _GNU_SOURCE DESCRIPTION malloc() La fonction malloc() alloue taille octets et renvoie un pointeur sur la memoire allouee. Le contenu de la zone de memoire n'est pas initialise. Si taille est nulle, malloc renvoie une valeur de pointeur unique qui pourra etre passee ulterieurement a free() avec succes (consulter << Comportement non portable >> pour les problemes de portabilite). free() La fonction free() libere l'espace memoire pointe par p qui doit avoir ete obtenu lors d'un appel anterieur a malloc() ou une fonction de la meme famille. Autrement, ou si p a deja ete libere, le comportement est indetermine. Si p est NULL, aucune operation n'est effectuee. calloc() La fonction calloc() alloue de la memoire pour un tableau de n elements de taille octets chacun et renvoie un pointeur sur la memoire allouee. La zone memoire est initialisee avec des 0. Si n ou taille vaut 0, calloc() renvoie une valeur de pointeur unique qui pourra etre passee ulterieurement a free() avec succes. Si la multiplication de n par taille provoque un depassement d'entier, calloc() renvoie une erreur. Par contre, aucun depassement d'entier ne serait detecte lors de l'appel suivant a malloc(), avec pour consequence l'allocation d'un bloc de memoire incorrectement dimensionne : malloc(n * taille); realloc() La fonction realloc() modifie la taille du bloc de memoire pointe par p a taille octets. Le contenu de la memoire entre la zone de depart et le minimum des ancienne et nouvelle tailles n'est pas modifie. Si la nouvelle taille est plus grande que l'ancienne taille, le contenu de la zone de memoire nouvellement allouee n'est pas initialise. Si p est egal a NULL, l'appel est equivalent a malloc(taille) pour toutes les valeurs de taille. Si taille est egale a zero et si p est different de NULL, l'appel est equivalent a free(p) (consulter cependant << Comportement non portable >> pour les problemes de portabilite). Excepte le cas ou p est egal a NULL, il doit avoir ete renvoye par un appel precedent a malloc ou a une fonction de la meme famille. Si la zone pointee a ete deplacee, l'appel free(p) est effectue. reallocarray() La fonction reallocarray() deplace eventuellement le bloc memoire pointe par p et change sa taille pour qu'il soit suffisamment grand pour contenir un tableau de n elements faisant chacun taille octets. Elle equivaut a l'appel realloc(p, n * taille); Cependant, contrairement a cet appel de realloc(), reallocarray() echoue pour eviter tout probleme dans le cas ou la multiplication entrainerait un depassement. Si un tel depassement se produit, reallocarray() renvoie une erreur. VALEUR RENVOYEE Les fonctions malloc(), calloc(), realloc() et reallocarray() renvoient un pointeur vers la memoire allouee qui est correctement alignee pour n'importe quel type dont la taille correspondra a la taille demandee ou sera inferieure a cette derniere. Si elles echouent, elles renvoient NULL et definissent errno pour indiquer l'erreur. Essayer d'allouer plus que PTRDIFF_MAX octets est considere comme une erreur, car un objet de cette taille pourrait provoquer un depassement lors d'une soustraction de pointeur ulterieure. La fonction free() ne renvoie aucune valeur et preserve errno. Les fonction realloc() et reallocarray() renvoient NULL si p est different de NULL et si la taille demandee est egale a zero, ce qui n'est pas considere comme une erreur (consulter << Comportement non portable >> pour les problemes de portabilite). Dans le cas contraire, le pointeur renvoye peut etre identique a p si la zone memoire n'a pas ete deplacee (par exemple s'il y a assez de place pour l'etendre a son emplacement), ou peut etre different de p si la zone memoire a ete deplacee a une nouvelle adresse. Si ces fonctions echouent, le bloc memoire originel reste intact ; il n'est ni libere ni deplace. ERREURS calloc(), malloc(), realloc() et reallocarray() peuvent echouer avec l'erreur suivante : ENOMEM Plus de memoire. Il est possible que l'application ait atteint les limites RLIMIT_AS ou RLIMIT_DATA decrites dans getrlimit(2). Une autre raison pourrait etre que le nombre de mappages crees par le processus appelant depasse la limite specifiee par /proc/sys/vm/max_map_count. ATTRIBUTS Pour une explication des termes utilises dans cette section, consulter attributes(7). +---------------------------------+--------------------------+---------+ |Interface | Attribut | Valeur | +---------------------------------+--------------------------+---------+ |malloc(), free(), calloc(), | Securite des threads | MT-Safe | |realloc() | | | +---------------------------------+--------------------------+---------+ NORMES malloc() free() calloc() realloc() C23, POSIX.1-2024. reallocarray() POSIX.1-2024. realloc(p, 0) Le comportement de realloc(p, 0) dans la glibc n'est conforme a aucune des normes C99, C11, POSIX.1-2001, POSIX.1-2004, POSIX.1-2008, POSIX.1-2013, POSIX.1-2017 ou POSIX.1-2024. La specification C17 a ete modifiee pour mettre cette fonction en conformite, mais cette specification a rendu impossible l'ecriture d'un code qui determinerait de maniere fiable si le pointeur d'entree a ete libere apres l'appel de realloc(p, 0), et C23 a encore modifie les choses pour rendre ce comportement indetermine, en assumant que la specification C17 etait suffisamment vaste, si bien qu'un comportement indetermine n'etait pas pire que ca. reallocarray() souffre du meme probleme dans la glibc. La libc de musl et celle de BSD sont conformes a toutes les versions de ISO C et POSIX.1. gnulib propose le module realloc-posix fournissant les programmes enveloppe realloc() et reallocarray() qui sont conformes a toutes les versions de ISO C. There's a proposal to standardize the BSD behavior: . 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 meme famille refusent les tailles superieures a PTRDIFF_MAX. Depuis la glibc 2.33, free() preserve errno. realloc(p, 0) C89 etait ambigu quant a sa specification de realloc(p, 0). C99 y remedie partiellement. L'implementation originelle dans la glibc aurait ete conforme a C99. Cependant, et ironiquement, en essayant de se conformer a C99 avant que la norme ne soit ecrite, glibc modifia son comportement a partir de glibc 2.1.1 pour quelque chose qui s'avera en fin de compte non conforme a la specification finale de C99 (mais cela est debattu, car la formulation de la norme semble se contredire elle-meme). NOTES Par defaut, Linux suit une strategie d'allocation optimiste. Cela signifie que lorsque malloc() ne renvoie pas NULL, il n'y a aucune garantie que la memoire soit veritablement disponible. S'il devait s'averer que le systeme manque de memoire, un ou plusieurs processus seraient tues par << OOM killer >> (gestionnaire de memoire). 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 general, malloc() alloue la memoire depuis le tas, et ajuste la taille du tas en consequence avec sbrk(2). Lorsque les blocs de memoire alloues sont superieurs a MMAP_THRESHOLD octets, l'implementation de la glibc de malloc alloue la memoire selon une projection anonyme privee avec mmap(2). MMAP_THRESHOLD vaut 128 ko par defaut et il est ajustable avec mallopt(3). Avant Linux 4.7, les allocations realisees avec mmap(2) n'etaient pas affectees 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 eviter les corruptions d'applications multithread, les mutex sont utilises en interne pour proteger les structures de donnees de gestion de memoire utilisees dans ces fonctions. Dans une application multithread ou les threads allouent et liberent la memoire en meme temps, ces mutex risquent d'entrer en conflit. Pour gerer l'allocation de memoire de facon evolutive dans les applications multithread, la glibc cree des domaines d'allocation memoire si un conflit de mutex est detecte. Chaque domaine est un grand espace de memoire qui est alloue en interne par le systeme (en utilisant brk(2) ou mmap(2)) et gere avec ses propres mutex. Si votre programme utilise un allocateur de memoire prive, il doit le faire en remplacant malloc(), free(), calloc() et realloc(). Les fonctions de remplacement doivent implementer les comportements de la glibc documentes, y compris la gestion de errno, les allocations de taille nulle et la surveillance des depassements ; si ce n'est pas le cas, d'autres routines de la bibliotheque pourront planter ou fonctionner de maniere incorrecte. Par exemple, si la fonction qui remplace free() ne preserve pas errno, des routines de la bibliotheque apparemment sans rapport pourront echouer sans indiquer de raison valable dans errno. Un allocateur de memoire prive devra peut-etre aussi remplacer d'autres fonctions de la glibc ; consulter << Remplacer malloc >> dans le manuel de la glibc pour plus de details. L'echec d'un allocateur de memoire est presque toujours le signe d'une corruption du tas, a l'instar d'un debordement de bloc memoire alloue ou d'une double liberation du meme pointeur. L'implementation de malloc() est personnalisable a l'aide des variables d'environnement. Pour plus de precisions, consultez mallopt(3). Comportement non portable Le comportement de ces fonctions lorsque la taille demandee est egale a 0 est specifique a la glibc ; d'autres implementations peuvent renvoyer NULL sans definir errno et les programmes POSIX portables doivent tenir compte de ces comportements. Consultez realloc(3p). La norme POSIX exige des allocateurs de memoire qu'ils renseignent errno en cas d'erreur. Ce n'est cependant pas le cas de la norme C, et les applications portables vers des plateformes non-POSIX ne sont donc pas tenues de se plier a cette contrainte. Les programmes portables ne doivent pas utiliser d'allocateurs de memoire prives, car les normes C et POSIX n'autorisent pas le remplacement des fonctions malloc(), free(), calloc() et realloc(). BOGUES Les programmeurs s'attendent naturellement par induction a ce que realloc(p, size) soit coherent avec free(p) et malloc(size), car c'est le comportement adopte dans le cas general. Ce comportement n'est pas explicitement impose par POSIX.1-2024 ou C11, mais toutes les implementations qui s'y conforment sont en accord avec cela. L'implementation de realloc() par la glibc n'est pas coherente avec ce comportement et par voie de consequence, il est dangereux d'utiliser realloc(p, 0) avec la glibc. Un contournement evident pour la glibc consiste a utiliser realloc(p, size?size:1). Le contournement pour la version de la glibc de reallocarray() -- qui partage le meme bogue -- consisterait a utiliser reallocarray(p, n?n:1, size?size:1). EXEMPLES #include #include #include #include #include #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 . TRADUCTION La traduction francaise de cette page de manuel a ete creee par Christophe Blaess , Stephan Rafin , Thierry Vignaud , Francois Micaux, Alain Portal , Jean-Philippe Guerard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas Francois , Florentin Duneau , Simon Paillard , Denis Barbier , David Prevot , Gregoire Scano et Lucien Gentis Cette traduction est une documentation libre ; veuillez vous reporter a la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a . Pages du manuel de Linux 6.17 8 fevrier 2026 malloc(3)