Discussion :

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

[Vincent Rogier]

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

??

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

[Melem]

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

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.

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

Justement, parce que c'est pas portable.

[souviron34]

euh !!!!!

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


donc errno oui, perror non

[Médinoc]

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

[Vincent Rogier]

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

[gl]

donc errno oui, perror non

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.

[souviron34]

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.

[gl]

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

[Melem]

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

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 :

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.

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.

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

[Vincent Rogier]

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 !

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

[Médinoc]

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

[Melem]

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.

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.

[souviron34]

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.

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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)

[Vincent Rogier]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Médinoc]

je plussoie également.

[nicolas.sitbon]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

return GetLastError();

[Melem]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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) ?

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.

[Melem]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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