À vrai dire, sous linux par défaut, malloc() et realloc() ne retournent finalement jamais NULL. Ce qu'il se passe plutôt, c'est qu'on reçoit toujours un pointeur, et c'est au moment où on se met à l'utiliser qu'il alloue réellement la mémoire.
Si au moment où on utilise la mémoire, celle-ci n'est pas disponible parce que la mémoire est pleine, alors le OOM-killer rentre en jeu et va tuer un process (que ça soit le process lui-même ou un autre).
Cette technique de lazy allocation permet notamment d'allouer plus de mémoire que ce qui est disponible physiquement (tant que toute cette mémoire allouée n'est pas utilisée). Ce comportement peut être modifié par des paramètres overcommit dans /sys/.
Cependant, même avec l'overcommit totalement désactivé, le noyau linux continuera à renvoyer un pointeur non-NULL, même quand il n'y a plus de mémoire disponible, et OOM-killer sera appelé comme d'habitude quand la mémoire sera accédée.
Au final sous linux il y a à priori une seule façon d'avoir ces fonctions qui retournent NULL, c'est en cas de fragmentation trop importante de l'espace d'adressage du processus qui rendrait impossible une allocation de la taille souhaitée, et c'est vraiment très très rare.
Voilà la raison pour laquelle vérifier le retour de malloc() et realloc() est en général assez peu utile, et pourquoi realloc() est assez souvent non testé pour NULL (les développeurs testent en général quand même avec malloc() car c'est plus facile à faire que avec realloc()).
Je préfère personellement quand même tester la valeur de retour quand même, ça permet d'être tranquille en cas de portage sur un autre unix, ça diminue les retours de logiciels d'analyse statique tel que clang et ça évite les questions en cas de revue de code.
# malloc() et realloc() sous linux
Posté par Damien Thébault . En réponse au journal realloc. Évalué à 10.
À vrai dire, sous linux par défaut, malloc() et realloc() ne retournent finalement jamais NULL. Ce qu'il se passe plutôt, c'est qu'on reçoit toujours un pointeur, et c'est au moment où on se met à l'utiliser qu'il alloue réellement la mémoire.
Si au moment où on utilise la mémoire, celle-ci n'est pas disponible parce que la mémoire est pleine, alors le OOM-killer rentre en jeu et va tuer un process (que ça soit le process lui-même ou un autre).
Cette technique de lazy allocation permet notamment d'allouer plus de mémoire que ce qui est disponible physiquement (tant que toute cette mémoire allouée n'est pas utilisée). Ce comportement peut être modifié par des paramètres overcommit dans /sys/.
Cependant, même avec l'overcommit totalement désactivé, le noyau linux continuera à renvoyer un pointeur non-NULL, même quand il n'y a plus de mémoire disponible, et OOM-killer sera appelé comme d'habitude quand la mémoire sera accédée.
Au final sous linux il y a à priori une seule façon d'avoir ces fonctions qui retournent NULL, c'est en cas de fragmentation trop importante de l'espace d'adressage du processus qui rendrait impossible une allocation de la taille souhaitée, et c'est vraiment très très rare.
Voilà la raison pour laquelle vérifier le retour de malloc() et realloc() est en général assez peu utile, et pourquoi realloc() est assez souvent non testé pour NULL (les développeurs testent en général quand même avec malloc() car c'est plus facile à faire que avec realloc()).
Je préfère personellement quand même tester la valeur de retour quand même, ça permet d'être tranquille en cas de portage sur un autre unix, ça diminue les retours de logiciels d'analyse statique tel que clang et ça évite les questions en cas de revue de code.