Ce sont des extensions BSD1, donc non POSIX et probablement pas très portable. Je préfère utiliser POSIX quand c'est possible.
Oui, l'un provoque un dump et pas l'autre. Si l'on veut un dump, on peut alors effectivement utiliser perror(1) puis abort(3).
Exactement, et je ne suis pas sur qu'un dump soit vraiment pertinent dans ce cas : une allocation qui échoue ce n'est pas un bug.
D'autant que : une segfault ou abort() provoque l’envoi du signal SIGSEGV (ou SIGABRT) et donc les fonctions enregistrées par atexit() ne seront pas exécutées. Le code de retour du processus sera supérieur à 128 ce qui signifie que le processus c'est terminé anormalement, etc...
1: Page de manuel Linux: « Conforming to: These functions are nonstandard BSD extensions. ». La page de manuel de FreeBSD précise qu'il faut privilégier strerror() pour du code portable : « The err() and warn() families of functions are BSD extensions. As such they should not be used in truly portable code. Use strerror() or similar functions instead. ».
[^] # Re: foobar
Posté par needs . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 2.
Ce sont des extensions BSD1, donc non POSIX et probablement pas très portable. Je préfère utiliser POSIX quand c'est possible.
Exactement, et je ne suis pas sur qu'un dump soit vraiment pertinent dans ce cas : une allocation qui échoue ce n'est pas un bug.
D'autant que : une segfault ou
abort()provoque l’envoi du signal SIGSEGV (ou SIGABRT) et donc les fonctions enregistrées paratexit()ne seront pas exécutées. Le code de retour du processus sera supérieur à 128 ce qui signifie que le processus c'est terminé anormalement, etc...1: Page de manuel Linux: « Conforming to: These functions are nonstandard BSD extensions. ». La page de manuel de FreeBSD précise qu'il faut privilégier
strerror()pour du code portable : « The err() and warn() families of functions are BSD extensions. As such they should not be used in truly portable code. Use strerror() or similar functions instead. ».