Par exemple ...Pourquoi les codes de retour supérieurs à 255 renvoient-ils un nombre différent en C++?
#include <iostream>
using namespace std;
int main(){return 300;}
Retours:
Process finished with exit code 44
??
La norme ne connaît que deux valeurs de retour standaradized: EXIT_SUCCESS (ou nul) et EXIT_- FAILURE:
3.6.1/5 Une instruction de retour dans le principal a pour effet de laisser la fonction principale (détruisant toute objets avec la durée de stockage automatique) et appelant
std::exitavec la valeur de retour comme argument.18.5/8 (...) Enfin, le contrôle est renvoyé à l'environnement hôte. Si l'état est zéro ou
EXIT_SUCCESS, une forme définie par l'implémentation de l'état aboutissement réussi est renvoyée. Si le statut estEXIT_- FAILURE, une forme définie par l'implémentation de l'arrêt d'état infructueux est renvoyée . Sinon, le statut renvoyé est défini par l'implémentation.
Il n'est donc pas garanti que tout autre nombre entier est renvoyé tel quel.
On MS Windows par exemple, la fonction retourne GetExitCodeProcess() la valeur entière de sorte que vous aurez 300.
Sur POSIX systèmes conformes, comme Linux, la règle est que (« seulement les 8 bits les moins significatifs (c.-à- statut & 0377) doit être disponible pour le processus parent en attente "". Donc, pour 300, ce sera 44.
En fait, sous unix, le code de sortie est dans le MSB, donc '(status & 0xff00) >> 8'. La raison pour seulement 8 bits est historique: sous unix original [développé pour le PDP-11], un 'int' était 16 bits, donc pas de place pour un code d'erreur plus grand dans' status' pour 'wait'. Pour des raisons de compatibilité ascendante, la taille du code d'erreur n'a pas été augmentée, même si la plupart des arcs définissent maintenant int comme une entité 32 bits. Comme mentionné, puisque le code retourné par un programme passe par le système d'exploitation et est obtenu par le parent à partir d'un syscall, il dépend du type de système d'exploitation –
@CraigEstey Intéressant, merci! En effet, j'ai trouvé dans "La conception du système d'exploitation unix" une note expliquant que les 8 bits inférieurs passés à 'exit()' sont stockés dans les bits 8 à 15 du code de retour du processus interne comme vous l'avez dit.Je suppose que c'est la raison pour laquelle le code de retour obtenu à partir de ['wait()'] (http://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html) doit être interprété correctement avec 'WIFEXITED () ',' WEXITSTATUS() 'et ainsi de suite ... Et de même pour le retour de [' system() '] (http://man7.org/linux/man-pages/man3/system.3.html). – Christophe
Merci à @HansPassant pour la mise à jour. En fait, la documentation Windows de 'exit()' dit "* l'octet de poids faible est mis à la disposition de l'environnement hôte *", mais le test montre que l'entier entier est toujours retourné, exactement comme vous l'avez dit par rapport à 'GetExitCodeProcess()'. Cela arrive même si vous utilisez l'héritage 'execlp()'. Il semble donc que l'absence du mot "seulement" doit être interprétée comme "le plus petit octet ou plus" :-) – Christophe
Cela ne prend que 8 bits. '300 & 0xff == 44'. Assez sûr que c'est surtout un truc Unix. Voir 'WEXITSTATUS' dans la page de manuel' waitpid' - le statut est OR'd dans d'autres valeurs. – asveikau
pourriez-vous expliquer pourquoi? et est-il possible de retourner un nombre plus élevé? – leszakk
Il n'existe pas de code de retour supérieur à 255. Le système d'exploitation ignore les bits au-delà des huit premiers. – EJP