Godzil (./7117) :
Pour le TL;DR:

Zeph si tu veux dire que les apps ne font pas des choses super compliqué pour gérer les cas d'allocation défaillante et quitter "gracieusement" (i.e. pas a coup d'abort ou assert), on est d'accord. cf le cas d'Apache. Il y a des cas ou faire un chemin de sortie "propre" est compliqué voir impossible.
Mais affirmer que la majorité des applications ne vérifient pas le retour de malloc est incorrect, un simple assert est une verification.

Le pas TL;DR

Non ca ne reviens pas au meme.

On ne peux pas comparer la gestion memoire d'un langage ou celle ci est automatique avec un language ou elle est manuelle.

Et parler de malloc est clairement parler d'un language manuel.
Python en interne vérifie que ses mallocs ne retourne pas NULL, mais toi programmeur Python ce n'est pas ton problème, tu ne sais meme pas ce qu'est un pointeur, et a peine ce qu'est de l'allocation mémoire.
Toi programmeur C, si tu appel malloc et tu ne vérifie pas que le pointeur est NULL, tu fais du mauvais code, c'est ton role de verifier que ce que tu fais et valide, et donc de verifier que malloc ne te retourne pas NULL.

Planter d'une manière controllé (appel a abort, assert, chaine complete pour retourner l'erreur et quitté "normalement" et non brutalement l'app) ou laisser l'app planter n'est pas semblable du tout.

Pour reprendre l'exemple de python, tu va te manger une exception de type "MemoryError" mais encore la la semantique est differente de celle de malloc, ou plutot, python verifie que son allocation en interne est possible et/ou qu'elle n'a pas foiré, et si elle foire il genere l'exception, mais si tu ne la catch pas ton app va stopper de maniere controllée, ca ne va pas planter au prochain acces mémoire sur le dit objet.

assert((ptr = malloc(10)) != NULL)
ptr[0] = 1;
est fondamentalement different de

ptr = returning_null_malloc(10);
ptr[0] = 1;

meme si l'arrêt est brutal.
Dans le premier cas tu est certains que l'app s'arrête si le pointeur est NULL, dans l'autre; si et seulement si 0 + déplacement ne tombe pas sur un emplacement mémoire alloué dans l'espace memoire de l'application.

Mon propos est, et je répète, dans tout langage a gestion manuelle de la mémoire tel que le C ou le C++; ne pas verifier que l'allocation ne foire pas d'une manière ou d'une autre est un bug parce que tu va planter de manière non contrôlée ou pire modifier de la mémoire que tu ne doit pas toucher.

C'est comme ca que dans les systèmes sans MMU on a des plantage a la con, pointeurs bancals, qui ne pointent pas au bon endroit ou allocation non vérifié, et on se retrouve a modifier la mémoire d'un autre process, voir pire de l'OS et la bonjour les dégâts... :/