Errno : usage et portabilité

Citation:

---

Envoyé par Melem

Le but était de montrer que Windows ne supporte pas totalement POSIX.1.

---

ah ok, la dessus je suis d'accord à 100%.

et là aussi je répète : dans une discussion de débutants (ce qui était le cas du post original) il est absolulement ridcule de parler d'utilser les messages par rapport aux codes.

Déjà, même dans un programme professionnel, ça le fait pas (voir les fameux "Fatal Error#0x0004FF" de Windows à un moment donné : tu t'en foutais pas mal de savoir quel était l'erreur.. Juste que ton système crashe pas!!!).

Donc résumons :

• dans 99% des cas, ce qu'on souhaite c'est savoir quelle erreur s'est produite afin d'agir dessus
• la pratique généralisée des codes professionnels est celle-ci
• dans 99% des cas les "sorties" (stderr, stdout) sont redirigées (souvent vers /dev/NULL) car la plupart des applications ont leurs propres fenêtres de messages d'erreur, avec leurs propres messages.
• la plupart des applications ne DOIVENT PAS s'arrêter lorsqu'une erreur survient.

Ce que la norme dit, c'est que, avant d'appeller une fonction de la bibliothèque, il faudrait que l'application set errno à zéro pour pouvoir vérifier son statut après l'appel :

Citation:

---

7.5 Errors <errno.h>
......
3 The value of errno is zero at program startup, but is never set to zero by any library function.172) The value of errno may be set to nonzero by a library function call whether or not there is an error, provided the use of errno is not documented in the description of the function in this International Standard.
......

172) Thus, a program that uses errno for error checking should set it to zero before a library function call,then inspect it before a subsequent library function call. Of course, a library function can save the value of errno on entry and then set it to zero, as long as the original value is restored if errno’s value is still zero just before the return.

---

PS: de plus, les messages étant beaucoup plus courts que l'explication du man page, la bonne démarche à adopter pour des débutants, comme pour des pros, est de verifier errno, et de regarder dans les man pages à quoi ça correspond. Que tu l'imprimes si tu veux, ça mange pas de pain. Mais il FAUT conseiller d'utiliser la VALEUR de errno pour agir...

Citation:

---

Envoyé par Médinoc

En effet, les sockets Windows ne mettent pas à jour errno.
Mais je te rassure tout de suite, perror() ne marche pas non plus...

---

Evidemment, puisque perror(msg) c'est :

Code:

---

fprintf(stderr, "%s: %s\n", msg, strerror(errno));

---

C'est fait pour afficher un message d'erreur, pas de prendre une décision en fonction d'un type d'erreur. Mais c'est 100% portable car on ne teste pas soi-même la valeur de errno (il n'y en a que 3 qui sont reconnues par la norme, tu les as déjà donné ...).

Citation:

---

Envoyé par souviron34

et là aussi je répète : dans une discussion de débutants (ce qui était le cas du post original) il est absolulement ridcule de parler d'utilser les messages par rapport aux codes.

---

Si tu veux déboguer un programme (Hypothèse : on est sur que la cause de la ause de l'erreur se trouve dans errno), que tu sois débutant ou pas, que vas-tu faire :

- faire un gros switch avec tous les codes d'erreurs possibles
- tester un code d'erreur, si c'est pas le bon on recompile avec un autre test
- afficher la descritption de la cause de l'erreur (perror)

?

Citation:

---

Envoyé par souviron34

Ce que la norme dit, c'est que, avant d'appeller une fonction de la bibliothèque, il faudrait que l'application set errno à zéro pour pouvoir vérifier son statut après l'appel :

---

Et en quoi ça implique que EINVAL par exemple est portable (approuvé par la norme) ?

Citation:

---

Envoyé par Melem

Si tu veux déboguer un programme (Hypothèse : on est sur que la cause de la ause de l'erreur se trouve dans errno), que tu sois débutant ou pas, que vas-tu faire :

- faire un gros switch avec tous les codes d'erreurs possibles
- tester un code d'erreur, si c'est pas le bon on recompile avec un autre test
- afficher la descritption de la cause de l'erreur (perror)

---

oui :mrgreen:

voir par exemple la manipulation des sockets et tous les cas d'erreurs...

PS:

J'ai COMPRIS !!!! tu parles de développement !! (voir ta 2ième possibilité) On parle d'applications.....

Erfff. On développe des applications pour qu'elles torunent...