Excuse moi mais si tu travaille dans un environnement un tant soit peu sérieux tu as des outils comme l'analyse statique ou équivalent (lint pour du C est suffisant pour ça par exemple) qui veille au grain pour ce genre de choses.

C'est le genre de test BASIQUE qui soit être systématiquement fait.

Je n'ai, a vrai dire, jamais vu du code de PRODUCTION, qui ne fasse pas ce genre de test. Dans du code reservé a a faire des test a la limite, mais en prod non.

C'est avec ce genre de pratiques/phrases qu'on se trouve avec des heartbleed. (meme si la ce n'est pas lie a un pointeur null)

beaucoup de bugs sont lié a une gestion de la memoire calamiteuse, donc oui un soft qui ne fait pas de test basique (meme un simple ASSERT(ptr != NULL); est suffisant, brutal mais suffisant) ne peux PAS etre mis en prod sans enorme risque.

D'ailleurs meme avec l'overcommit malloc peux quand meme répondre NULL sous linux. (sous une version 32bit essaye d'allouer plus de 3Go au total tu va voir..)


Et si vraiment tu as la FLEMME de faire toi meme pour chaque allocation, tu fait une fonction genre

void *safe_alloc(size_t sz) { void *ptr = calloc(sz); ASSERT(ptr != NULL); return ptr; }
Et ne fait plus appeil a malloc directement mais a safe_alloc.

Un pointeur null + dereferencement, au meilleurs des cas on a un segfault. Sauf si on a une operation de type (pointer + X) et la.. on va potentiellement lire de la memoire si elle est alloué dans la MMU.

Donc tu fait comme tu veux, mais une app qui ne gere pas la memoire correctement n'a absolument rien a faire en production.

Donc non assumer que malloc ne retourne JAMAIS une erreur est un probleme, Et non j’espère vraiment que la "quasi-totalité des programmes utilisés sur n'importe quelle plate-forme de production ne teste jamais la réussite des appels à malloc" parce qu'on aurais vraiment pas mal d'emmerdes a cause de ca, et je peux t'assurer que tout code un tant soit peu serieux (et qui doit l'etre) qui me soit passé dans les main ne part pas du principe que malloc ne retourne jamais une erreur, c'est meme plutot le contraire, il faut TOUJOURS assumer que tout peux foirer


edit: un exemple de ce dont je veux parler sur le fait que c'est une faille potentielle:
#include <stdio.h> #include <stdint.h> int main() { char *ptr = NULL; char ascii[] = "Hello World"; uint64_t depl = (uint64_t)&ascii[0]; printf("ptr = %p\n", ptr); printf("ptr[depl] = %p\n", &ptr[depl]); printf("ascii = %p\n", &ascii[0]); printf("%s\n", &ptr[depl]); return 0; }
Ce code marche sans probleme:

ubuntu@ubuntu-armhf:~$ ./test 
ptr       = (nil)
ptr[depl] = 0xbec32b90
ascii     = 0xbec32b90
Hello World

Suivant ce que fait le code, un malloc foireux peux etre exploité pour acceder a de la memoire, c'est une faille de securite au meme titre que ne pas verifier ta requete SQL ou faire un eval($_GET['bla']) ou include($_GET['bla']) en PHP.

Au contraire tout projet serieux fait super attention a l'allcoation memoire, exemple:

https://www.nginx.com/resources/wiki/extending/api/alloc/#ngx-alloc
utilisaton: https://github.com/nginx/nginx/blob/0f89206a1078a216961d974ed5bcf6464b65cbdf/src/event/modules/ngx_devpoll_module.c#L151

Apache fait un abort en cas d'erreur d'allocation:
https://github.com/apache/httpd/blob/f3a50c0902efd798f80c6b86290e0bddf26b2843/server/util.c#L3109
(ap_abort on oom: https://github.com/apache/httpd/blob/f3a50c0902efd798f80c6b86290e0bddf26b2843/server/util.c#L3093 )

Si tu trouve un application qui est fait pour de la production et qui ne gère pas l'allocation mémoire correctement c'est un bug report direct !