Godzil (./7117) :
Mais affirmer que la majorité des applications ne vérifient pas le retour de malloc est incorrect, un simple assert est une verification.

Quelle est la différence que tu veux mettre en avant ? Ton propos, en ./7108, était que toutes les applications devraient "tester si malloc retourne NULL" mais tu n'as pas expliqué l'objectif que tu cherches à atteindre.

En C, un échec d'allocation est signalé par un retour de NULL que tu es supposé vérifier. Si tu oublies de le faire, soit ton application va se mettre à avoir un comportement totalement imprévisible, soit -plus probable- elle va planter immédiatement après en essayant de déréférencer un pointeur nul. En C++, un échec d'allocation sera signalé par l'un des opérateurs "new" en jetant une exception que personne ne pense jamais à attraper, il en résulte le plus souvent un plantage immédiat de l'application. En Python, Java, C# ou dans toute une autre tripotée de langages à mémoire managée, un échec d'allocation sera signalé par une exception système qu'il est recommandé de ne pas intercepter, il en résulte là encore un plantage immédiat de l'application.

Je passe sur les détails de log, de dumps ou de contexte qui peuvent expliquer comment c'est arrivé, le résultat est le même : on a une application qui a été interrompue en plein milieu de son exécution et tous ses effets de bords n'ont pas été nettoyés correctement. On a des fichiers à moitié écrits, des données qui trainent dans des dossiers temporaires ou des /var/machin, des changements qui n'ont pas été sauvegardés, etc. Dans aucun cas c'est un comportement souhaitable et je ne vois pas trop ce que le langage qui est derrière vient changer ici. Donc pour moi, non, ajouter un assert(malloc() != null) ne change rien au problème, on y gagne peut-être quelques infos de debug mais l'application n'est pas devenue plus robuste pour autant.

La seule façon de gérer le manque de mémoire aurait été de continuer l'exécution en se passant de la mémoire qui n'a pas pu être obtenue. Bien sûr que c'est possible, mais en-dehors d'applications critiques personne ne fait ça aujourd'hui. C'est dommage, c'est de la fainéantise ou tout ce que tu veux mais c'est comme ça. Et c'est une situation qui me semble tellement impossible à réfuter que je m'épargne des liens, je pense qu'une simple recherche sur "malloc" ou "new" dans des projets GitHub connu sera une illustration suffisante de l'état de l'art dans ce domaine.