J'ai vu sur ma plate-forme vxWorks 6 appeler write sur un socket avec succès et retourner le nombre d'octets demandés à écrire, mais aussi transformer errno de 0 à 19 (ENODEV).Peut-on définir errno en cas de succès?
J'ai trouvé cela plutôt surprenant.
Une erreur peut-elle être définie après une opération réussie?
Sur Wikipédia errno.h dit:
Une valeur (le numéro d'erreur) est stocké dans errno par certaines bibliothèques fonctions quand ils détectent les erreurs. Au démarrage du programme, la valeur enregistrée est zéro. Les fonctions de bibliothèque ne stockent que les valeurs supérieures à zéro. Toute fonction de bibliothèque peut modifier la valeur stockée avant le retour, que ce soit ou non, ils détectent des erreurs. La plupart des fonctions indiquent qu'elles ont détecté une erreur en retournant une valeur spéciale, généralement NULL pour les fonctions renvoyant des pointeurs, et -1 pour les fonctions qui renvoient des entiers. Quelques fonctions exigent que l'appelant prérigne errno à zéro et le testent ensuite pour voir si une erreur a été détectée.
Donc, en dehors de la valeur bizarre de ENODEV pour une prise write il semble raisonnable de penser que certaines opérations internes mis errno et write récupéré (ou ne se souciaient pas) mais n'a pas été autorisé à remettre errno à 0 ou à ce qu'il était avant.
L'implication est que errno ne peut pas être considérée comme significative, sauf immédiatement après une fonction dont la valeur retournée indique que errno est significatif. De là découle l'idée que errno ne peut pas être utilisé par la suite pour déduire une défaillance parmi une séquence de errno -influencer des opérations.
Une telle utilisation ne peut être possible que si les fonctions de la bibliothèque ne sont pas de compensation errno milieu de séquence, mais parce qu'ils ne errno pas clair, les conditions d'erreur internes sont récupérées encore reflétées dans errno.
Si vous avez besoin de savoir si une fonction a échoué, vous devez vérifier son résultat immédiatement et consulter errno uniquement si cela s'applique.
Vous ne pouvez pas utiliser la variable partagée globale errno pour activer l'état de sortie du tunnel via une hiérarchie d'appels de fonction sans renvoyer également indépendamment le statut de succès/échec par d'autres moyens.