Errno : usage et portabilité

Ce n'est pas une bonne habitude de tester errno. Pour faire du code portable, il vaut mieux appeler perror (affiche la description de l'erreur) ou strerror (récupère la description de l'erreur), respectivement déclarées dans stdio.h et string.h. (perror utilise strerror qui utilise errno ...)

Citation:

---

Envoyé par Melem

Ce n'est pas une bonne habitude de tester errno. Pour faire du code portable, il vaut mieux appeler perror (affiche la description de l'erreur) ou strerror (récupère la description de l'erreur), respectivement déclarées dans stdio.h et string.h. (perror utilise strerror qui utilise errno ...)

---

8O8O ??

strerror() et perror() renvoient une chaine de caractères descriptive de l'erreur dont le code est détenu par errno...

Ces chaines de caractères sont dépendantes de l'implémentation... donc leur interprétation non portable...

Alors que pour errno, bien que des valeurs spécifiques soient dépendante des implémentations, une série de valeurs sont communément fournies et font partie des normes POSIX.

De plus si on veut juste tester un certain code erreur, seul errno le permet.

Alors dire que utiliser errno est moins portable que perror() /strerror(), ça m'en bouche un coin......

Citation:

---

strerror() et perror() renvoient une chaine de caractères descriptive de l'erreur dont le code est détenu par errno...

---

C'est ce que j'ai dit, mais au moins ça nous évite de tester la valeur de errno. Donc si on veut du code 100% conforme à la norme (pas conforme à 99.99 %), il faut se limiter à l'usage de perror ou strerror (et là encore je préfère strerror ...)

Citation:

---

Ces chaines de caractères sont dépendantes de l'implémentation... donc leur interprétation non portable...

---

Le programmeur n'a pas besoin de savoir ce que va afficher cette chaîne, c'est l'utilisateur qui en a besoin.

Citation:

---

De plus si on veut juste tester un certain code erreur, seul errno le permet.

---

Justement, parce que c'est pas portable.

euh !!!!!
8O
en général c'est pour pouvoir traiter les cas, pas pour afficher la chaine..

Donc l'utilisateur s'en fout, mais le programmeur non...
8O

donc errno oui, perror non :D

D'accord avec vicenzo et souviron34.
Quand le programme doit traiter l'erreur, perror() et strerror() ne servent à rien.
Seule errno peut être traitée, en la comparant à des constantes dont le nom est standardisé.

Citation:

---

Envoyé par Melem

C'est ce que j'ai dit, mais au moins ça nous évite de tester la valeur de errno. Donc si on veut du code 100% conforme à la norme (pas conforme à 99.99 %), il faut se limiter à l'usage de perror ou strerror (et là encore je préfère strerror ...)

Le programmeur n'a pas besoin de savoir ce que va afficher cette chaîne, c'est l'utilisateur qui en a besoin.

Justement, parce que c'est pas portable.

---

Encore un fois, les valeurs affectées par la libc à errno sont définies et portables sur les systèmes POSIX

De plus, une logique applicative ne se contente pas d'afficher une message d'erreur en cas de problème !!!!!!!!!!!

Une logique applicative efficace consiste à analyser l'erreur grace à errno et décider de la suite du process en fonction du code erreur.

Le programmeur s'en fout du message d'erreur. De plus, un message d'erreur en anglais fourni par le compilo n'est pas vraiment parlant pour un utilisateur lambda.

Une application qui repose sur les messages de perror() ne peut être professionnelle et efficace....

Citation:

---

Envoyé par souviron34

donc errno oui, perror non :D

---

Pourquoi être aussi affirmatif ?

Il s'agit de mécanismes certes liés mais distincts et dont l'utilisation n'est pas la même :
* s'il s'agit de tester la raison de l'erreur pour effectuer le traitement adéquate, il faut utiliser errno (avec toutes les conditions d'utilisation que cela sous entends)
* s'il s'agit d'afficher le motif, on utilise perror().
* s'il s'agit de logguer dans un fichier l'erreur (ou un autre traitement du même type, il faut voir du côté de strerror().

En sachant que leur utilisation n'est pas exclusive.

Citation:

---

Envoyé par gl

Pourquoi être aussi affirmatif ?

Il s'agit de mécanismes certes liés mais distincts et dont l'utilisation n'est pas la même :
* s'il s'agit de tester la raison de l'erreur pour effectuer le traitement adéquate, il faut utiliser errno (avec toutes les conditions d'utilisation que cela sous entends)
* s'il s'agit d'afficher le motif, on utilise perror().
* s'il s'agit de logguer dans un fichier l'erreur (ou un autre traitement du même type, il faut voir du côté de strerror().

En sachant que leur utilisation n'est pas exclusive.

---

;) je parlais en réponse au post précédent...

Si l'on veut traiter les cas d'échec, une seule méthode : errno.

Ce qui était bien ce qui était demandé en réponse au message du PO.

Citation:

---

Envoyé par souviron34

Si l'on veut traiter les cas d'échec, une seule méthode : errno.

---

De mon point de vue, tracer l'erreur est deja une forme de traitement de l'erreur:D

En réponse à vicenzo, Médinoc et souviron34 : je crois qu'on va devoir un peu reprendre depuis le début :

Citation:

---

Envoyé par vicenzo

Il peut y avoir plusieurs raison (la plus courante est celle mentionnées par ram_0000).

Pour savoir qu'elle est l'erreur, (si rename() retourne -1), examines la valeur de errno.

---

Donc ici (sur ce thread), on veut apparemment déboguer. La méthode la plus rapide (et totalement portable) pour y arriver c'est d'afficher la description de l'erreur avec perror.

En ce qui concerne l'utilisation de errno en général :

Citation:

---

Envoyé par vicenzo

Encore un fois, les valeurs affectées par la libc à errno sont définies et portables sur les systèmes POSIX

---

Je n'ai jamais affirmé le contraire. Mais tous les systèmes ne sont pas POSIX.

Citation:

---

Envoyé par Melem

Donc si on veut du code 100% conforme à la norme (pas conforme à 99.99 %), il faut se limiter à l'usage de perror ou strerror (et là encore je préfère strerror ...)

---

Le respect de la norme implique contraintes, moins de liberté. Tester errno avec des valeurs qui ne sont pas définis par la norme est un non respect de la norme.

Citation:

---

Envoyé par vicenzo

De plus, une logique applicative ne se contente pas d'afficher une message d'erreur en cas de problème !!!!!!!!!!!

Une logique applicative efficace consiste à analyser l'erreur grace à errno et décider de la suite du process en fonction du code erreur.

---

J'ai parlé ici uniquement de la norme, pas d'autre chose. On a GetLastError, WSAGetLastError, etc. sous Windows par exemple. Rien à voir avec errno. Ou bien fais des programmes utilisant les sockets sous Windows et teste les erreurs avec errno, ce sera déjà moins drôle ...

Citation:

---

Envoyé par Melem

En ce qui concerne l'utilisation de errno en général :
Je n'ai jamais affirmé le contraire. Mais tous les systèmes ne sont pas POSIX.

---

Sur ce coup, la plupart des OS sont conformes POSIX.1, même MS Windows !

Citation:

---

Envoyé par Melem

le respect de la norme implique contraintes, moins de liberté. Tester errno avec des valeurs qui ne sont pas définis par la norme est un non respect de la norme.

---

La norme ne précise quasiment rien sur les valeurs de errno ! Donc selon toi l'utilisation de errno est hors normes ! Ben la je ne suis pas d'accord. L'existence de errno est définie par la norme donc son utilisation est 'conforme' à la norme.

Pour résumer le seul moyen portable de gérer des erreurs en C, en respectant la norme et en étant portable, afin de réagir à ces erreurs est errno !

Mais peux être que tu connais un autre moyen ??

Errno est le seul moyen pour un traitement de décider la marche à suivre en cas d'erreur.

L'affichage du texte de l'erreur ne sert à rien à un processus

Et enfin, tous les systèmes POSIX ont la même base de valeurs pour errno...

La plupart des systèmes respectent le standard POSIX pour ce qui est d'errno.
De plus, les erreurs EDOM, EILSEQ et ERANGE sont standard C (bien qu'ici, elles ne soient pas en jeu).

Enfin, on n'affiche évidemment pas les valeurs numériques pour errno: Pour l'affichage, on utilise perror() ou strerror() (la seconde n'étant ni réentrante, ni garantie thread-safe)...

Citation:

---

Envoyé par vicenzo

Sur ce coup, la plupart des OS sont conformes POSIX.1, même MS Windows !

---

Windows support une partie de POSIX.1. fork par exemple n'est pas implémentée, pour les sockets, les numéros d'erreurs ne sont pas récupérables dans errno mais via WSAGetLastError, etc.

Citation:

---

Envoyé par Médinoc

De plus, les erreurs EDOM, EILSEQ et ERANGE sont standard C (bien qu'ici, elles ne soient pas en jeu).

---

Oui, ce sont les seules valeurs de errno spécifiées par la norme, d'autres valeurs sont possibles mais doivent toujours commencer par un E majuscule et sont évidemment "implementation defined". POSIX a défini des codes d'erreurs supplémentaires. Quelques uns de ces codes existent sous Windows.

Citation:

---

Envoyé par Melem

Windows support une partie de POSIX.1. fork par exemple n'est pas implémentée, pour les sockets, les numéros d'erreurs ne sont pas récupérables dans errno mais via WSAGetLastError, etc.

Oui, ce sont les seules valeurs de errno spécifiées par la norme, d'autres valeurs sont possibles mais doivent toujours commencer par un E majuscule et sont évidemment "implementation defined". POSIX a défini des codes d'erreurs supplémentaires. Quelques uns de ces codes existent sous Windows.

---

8O
mais qui a dit de tester par rapport à la valeur numérique ?????????????????????
8O

Code:

---

1 2	if (errno == EINVAL)

---

est portable, correspond à la norme, et sert justement à faire ce qu'on veut...

Melem, tu t'enfonces là...

Personne n'a suggéré de faire

Code:

---

if ( errno == 17)

---

En tous cas, conseiller d'utiliser des perror et autres est une absurdité du point de vue de la programmation, à moins que tu ne fasses que des petites applis qui s'arrêtent à la moindre erreur.

Mais ce n'est pas une bonne pratique à enseigner pour faire un bon code
(la plupart des codes professionnels ne devant PAS s'arrêter à la moindre erreur)

Citation:

---

Envoyé par souviron34

8O
mais qui a dit de tester par rapport à la valeur numérique ?????????????????????
8O

Code:

---

1 2	if (errno == EINVAL)

---

est portable, correspond à la norme, et sert justement à faire ce qu'on veut...

Melem, tu t'enfonces là...

Personne n'a suggéré de faire

Code:

---

if ( errno == 17)

---

En tous cas, conseiller d'utiliser des perror et autres est une absurdité du point de vue de la programmation, à moins que tu ne fasses que des petites applis qui s'arrêtent à la moindre erreur.

Mais ce n'est pas une bonne pratique à enseigner pour faire un bon code
(la plupart des codes professionnels ne devant PAS s'arrêter à la moindre erreur)

---

+1

je plussoie également.

Citation:

---

Envoyé par Melem

pour les sockets, les numéros d'erreurs ne sont pas récupérables dans errno mais via WSAGetLastError, etc.

---

Autant que je me souvienne, ça n'est pas limité au socket mais à toutes les APIs, dont le code d'erreur peut être retrouvé grâce à GetLastError().
Au passage WSAGetLastError = GetLastError.
WSAGetLastError n'est qu'une relique du temps du 16bits et n'est la que pour compatibilité, d'ailleurs si on jète un coup d'oeil au code source de WSAGetLastError on trouve :

Code:

---

return GetLastError();

---

Citation:

---

Envoyé par souviron34

8O
mais qui a dit de tester par rapport à la valeur numérique ?????????????????????
8O

Code:

---

if (errno == EINVAL)

---

est portable, correspond à la norme, et sert justement à faire ce qu'on veut...

---

La norme ne parle pas de EINVAL, peux-tu me dire pourquoi c'est portable (ISO, pas POSIX) ?

Citation:

---

Envoyé par souviron34

En tous cas, conseiller d'utiliser des perror et autres est une absurdité du point de vue de la programmation, à moins que tu ne fasses que des petites applis qui s'arrêtent à la moindre erreur.

Mais ce n'est pas une bonne pratique à enseigner pour faire un bon code
(la plupart des codes professionnels ne devant PAS s'arrêter à la moindre erreur)

---

Et là aussi je répète, je ne parle ici que du point de vue NORME. Ne parlons pas d'autre chose, ça va rendre cette discussion inutilement encore plus longue. Personne ici n'a dit que ceux qui ont introduit les codes d'erreurs sont fous, que les codes d'erreurs çà ne sert à rien.

Citation:

---

Envoyé par nicolas.sitbon

Autant que je me souvienne, ça n'est pas limité au socket mais à toutes les APIs, dont le code d'erreur peut être retrouvé grâce à GetLastError().
Au passage WSAGetLastError = GetLastError.
WSAGetLastError n'est qu'une relique du temps du 16bits et n'est la que pour compatibilité, d'ailleurs si on jète un coup d'oeil au code source de WSAGetLastError on trouve :

Code:

---

return GetLastError();

---

---

Le but était de montrer que Windows ne supporte pas totalement POSIX.1. D'après la norme POSIX, les codes d'erreurs liées aux fonctions de l'interface des sockets doivent être placés dans errno, ce qui n'est pas le cas sous Windows ...

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

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...