C'est pour ça que tu vas allouer de la mémoire au lancement du programme pour avoir une "réserve" pour ce genre de cas.
Bah voyons, montre-moi tu empêches fprintf() ou un appel système de retourner ENOMEM en cas de OOM, je suis curieux.
Tu en sais quoi qu'il pourrait crasher n'importe quoi ?
Tout les process peuvent crasher, à n'importe quel moment : OOM, signal, mémoire défectueuse…
Le seul critère est l'impact du crash : et dans ce cas, un logiciel non critique, sans persistance de données, sans effets de bords, l'impact est négligeable.
Ou alors le programme indique clairement : "attention ce programme ne gère pas du tout la mémoire, il ne faut donc pas l'utiliser à part si vous n'en avez pas besoin" !
OK, donc explique-moi ce que tu pourrais faire de plus qu'un _exit() en cas de OOM sur ce programme précis (parce qu'on parle de celui-là, toute la question est de la pertinence d'une telle gestion en fonction de la criticité). Si ton programme ne peut plus fonctionner correctement, autant le terminer pour remonter l'erreur que de continuer et faire n'importe quoi, non (encore une fois, je parle de programmes non critiques) ?
Soyons sérieux, tu gueules si un appareil électrique grille à la première surtension. Pourtant il est prévu pour le réseau standard, donc pourquoi mettre un fusible ? Et finalement, c'est juste un gadget, pas un appareil critique, ce n'est pas grave s'il grille : il suffit de le ramener sous garantie. Sauf que ta maison à cramer à cause de ce raisonnement.
OK, quand je vois ce genre de comparaisons, je me dis que ce n'est pas la peine de discuter…
Tu compares une installation électrique à un gadget GUI qui t'affiche ta consommation CPU.
Si tu ne fais pas la différence de criticité entre les deux, je ne peux rien pour toi…
Si en Java, OutOfMemoryError est une Error, et pas une checked exception, il y a une raison…
Par ailleurs, je ne vois toujours pas le lien entre realloc() et la fuite mémoire, tu devrais utiliser valgrind au lieu de patcher le code au petit bonheur la chance…
[^] # Re: criticité
Posté par neologix . En réponse au journal Genèse d'un journal. Évalué à 0.
Bah voyons, montre-moi tu empêches fprintf() ou un appel système de retourner ENOMEM en cas de OOM, je suis curieux.
Tout les process peuvent crasher, à n'importe quel moment : OOM, signal, mémoire défectueuse…
Le seul critère est l'impact du crash : et dans ce cas, un logiciel non critique, sans persistance de données, sans effets de bords, l'impact est négligeable.
OK, donc explique-moi ce que tu pourrais faire de plus qu'un _exit() en cas de OOM sur ce programme précis (parce qu'on parle de celui-là, toute la question est de la pertinence d'une telle gestion en fonction de la criticité). Si ton programme ne peut plus fonctionner correctement, autant le terminer pour remonter l'erreur que de continuer et faire n'importe quoi, non (encore une fois, je parle de programmes non critiques) ?
OK, quand je vois ce genre de comparaisons, je me dis que ce n'est pas la peine de discuter…
Tu compares une installation électrique à un gadget GUI qui t'affiche ta consommation CPU.
Si tu ne fais pas la différence de criticité entre les deux, je ne peux rien pour toi…
Si en Java, OutOfMemoryError est une Error, et pas une checked exception, il y a une raison…
Par ailleurs, je ne vois toujours pas le lien entre realloc() et la fuite mémoire, tu devrais utiliser valgrind au lieu de patcher le code au petit bonheur la chance…