Est-il nécessaire de vérifier la valeur NULL après l'affectation de la mémoire, lorsque le noyau utilise la surcharge de la mémoire

Question

Il est de pratique générale pour vérifier la valeur NULL (si la mémoire est correctement alloué) après un malloc(), quelque chose comme

void *ptr = malloc(10);    
if (ptr != NULL) {  
  // do some thing usefull  
} else {  
 // no memory. safely return/throw ...  
}  

avec de surcharge de mémoire est activé dans le noyau, est-il une chance d'obtenir la NULLE?Dois-je suivre la pratique des religieusement la vérification de la valeur NULL pour chaque allocation?Va malloc renvoie NULL en dépit de chien agressif de surcharge de mécanisme (je suppose que la valeur 1)?

Comme une question de fait Android noyau utilise la surcharge de mémoire (pas sûr de la valeur, aimerais savoir c'(surcharge de valeur) et sa signification).Certains le cadre source C/C++) du code de Android (peut-être 3ème partie) ne vérifie pas la valeur NULL, ni attraper bad_alloc après attribution.Ai-je raté quelque chose?

Il y a quelques threads, DONC en ce qui concerne de surcharge de la mémoire, mais aucun n'a résolu mon désarroi.

EDIT: Si agressif de surcharge est employé NULLE ne sera pas retourné(hypothèse 1).Quand il n'y a pas de mémoire physique disponible et sur essayer d'accéder à la mémoire allouée (écrire dans la mémoire allouée), OOM va tuer le processus et alloue de la mémoire pour l'application jusqu'à ce qu'il se fait tuer à son tour(hypothèse 2).Dans les deux cas je ne vois aucune nécessité de cheque NULL (de mémoire allouée ou processus de se faire tuer).je suis droit dans mes hypothèses?
La portabilité n'est pas un souci pour cette question.

Answer 1

Oui, vous devriez toujours vérifier les échecs retourné par malloc.Dans un environnement qui overcommits de la mémoire, vous ne serez pas en mesure de détecter et de récupérer à partir de défaillances dues à l'environnement en cours d'exécution hors de physique de stockage requis lorsque vous écrivez à des parties de l'espace d'adressage qui ont été attribués à votre programme par un appel précédent à malloc.

Cependant, ce n'est pas le seul problème qui serait la cause d'une malloc l'échec dans un environnement traditionnel.Une demande pour un particulièrement grand bloc de mémoire lorsque l'espace d'adressage du programme a été fragmenté peut échouer même si il est potentiellement assez de mémoire physique totale pour satisfaire la demande.Car il n'y a pas de plage contiguë de gratuit espace d'adressage malloc doit échouer.Ce type de défaillance doit être signalée par malloc de retour NULL, ou non , si l'environnement est overcommitting de la mémoire.

Answer 2

Vous devez vérifier la valeur de retour la valeur NULL chaque temps.Une bibliothèque de fonction peut échouer.Même la fonction fclose() do (sur déconnecté partage NFS, et l'erreur de la fonction fclose de fichiers NFS signifie que les données ne sont pas enregistrées).

La plupart des logiciels est mal écrit et ne contient pas tous les contrôles.

malloc ne pouvez pas retourner quelque chose d'autre que NULL ou un pointeur.Tout-ou-rien.Vous ne pouvez pas obtenir 1 octet de malloc, si vous demandez à 10.

Answer 3

Il serait souhaitable de vérifier la valeur NULL religieusement dans tous les appels de fonctions que peut retourner NULL, indépendamment du fait que le noyau a committable de la mémoire ou non.

Ce segment de code suivant ci-dessous montre comment vérifier si l'appel à malloc travaillé ou pas...

void *ptr = malloc(10);
if (ptr != NULL){
   /* Do something here with ptr */
}else{
   /* Do something here if it fails */
}

Opérations sur les fichiers, les opérations de mémoire pour n'en nommer que quelques renvoie NULL en cas d'échec.

Espérons que cela aide, Meilleures salutations, Tom.

Answer 4

bien...sur Linux depuis la mémoire n'est pas la page soutenu (au début) et ne crée que de la page de sauvegarde après la première lecture/écriture, le système d'exploitation réussira toujours à vous donner de la mémoire (sauf si vous avez épuisé l'adresse de l'espace, quelque chose de pas possible dans les systèmes 64 bits).Donc, si elle est à court de mémoire et ne peut pas vous donner la promesse de la mémoire, de l'OOM killer va juste tuer votre demande ou à une autre application pour vous donner la page de soutien dont vous avez besoin.Donc, si vous ne le NUL de vérifier ou non, le sort est le même, un crash.......

Answer 5

Non, il n'est pas nécessaire pour vérifier le résultat de la fonction malloc.

Longtemps avant malloc échouerait, le système d'exploitation avait déjà rencontré beaucoup de problèmes.

"OOM-Killer et de surcharge" serait un meilleur choix.

Quoi?Votre système d'exploitation ne prend pas en charge "OOM-Killer et de gestion du dépassement"?

C'est pourquoi vous devez passer à Linux （ou Android）!