• [^] # Re: Ne le fait pas.

    Posté par (site web personnel) . En réponse au journal realloc. Évalué à 6.

    Bien sûr il y a des cas ou c'est nécessaire de gérer ça correctement (en embarqué par exemple). Mais pas ici.

    Pour être plus précis: les cas en questions sont assez nombreux et dépendent du contexte d'éxécution. Quand tu programme tu ne sais souvent pas où ton code va finir après avoir été (削除) copié/collé (削除ここまで)refactoré vingt fois.

    Le mieux que tu puisse faire c'est un truc du style [assert]

    Pour donner un autre exemple sur un serveur ou dans une bibliothèque c'est vraiment pas ce qu'il y a de mieux à faire. Il faut tester et respectivement renvoyer une erreur au client (par ex indiquant de réessayer après un temps d'attente exponentiel en fonction du nombre d'erreurs) ou renvoyer à l'appelant un truc qui lui permet de faire ce qui convient.

    Tout ce que tu fais c'est perdre des cycles à tester et rajoute du code qui prends de la place en cache

    Et accessoirement te conformer à l'API.

    C'est impossible de tester tout les cas possible d'échec de realloc. Et du code non testé à de forte chance de ne pas fonctionner

    C'est pourtant facile d'injecter ce genre d'erreur.

    Les systèmes d'exploitation moderne "overcommit" la mémoire

    Ça dépends entre autres de l'humeur de ton sysadmin, et dans tout les cas c'est pas dans l'API.