nouveau en C je ne sais trop comment gérer de codes d'erreurs.
ce que je souhaite|projette de faire :
avoir une sorte de hash table du style :
0 => "Pas d'erreur"
1 => "Problème d'allocation mémoire"
2 => "Fichier inexistant"
etc...
donc comme mon extension C pour Ruby retourne un objet ruby je souhaite
ajouter, par exemple une fonction du type "errno" et une autre "errmsg"
cette dernière donnant - en clair - le mesage d'erreur en anglais (je
n'envisage pas d'internationalisation).
y a t'il un tuto qqpart sur ce sujet ?
nouveau en C je ne sais trop comment gérer de codes d'erreurs.
ce que je souhaite|projette de faire :
avoir une sorte de hash table du style :
0 => "Pas d'erreur"
1 => "Problème d'allocation mémoire"
2 => "Fichier inexistant"
etc...
donc comme mon extension C pour Ruby retourne un objet ruby je souhaite
ajouter, par exemple une fonction du type "errno" et une autre "errmsg"
cette dernière donnant - en clair - le mesage d'erreur en anglais (je
n'envisage pas d'internationalisation).
y a t'il un tuto qqpart sur ce sujet ?
nouveau en C je ne sais trop comment gérer de codes d'erreurs.
ce que je souhaite|projette de faire :
avoir une sorte de hash table du style :
0 => "Pas d'erreur"
1 => "Problème d'allocation mémoire"
2 => "Fichier inexistant"
etc...
donc comme mon extension C pour Ruby retourne un objet ruby je souhaite
ajouter, par exemple une fonction du type "errno" et une autre "errmsg"
cette dernière donnant - en clair - le mesage d'erreur en anglais (je
n'envisage pas d'internationalisation).
y a t'il un tuto qqpart sur ce sujet ?
En C standard on sort, d'une façon normale, du programme par un "return x"
dans le main ou par un "exit(x)". Le "x" peut avoir 3 valeurs : 0,
En C standard on sort, d'une façon normale, du programme par un "return x"
dans le main ou par un "exit(x)". Le "x" peut avoir 3 valeurs : 0,
En C standard on sort, d'une façon normale, du programme par un "return x"
dans le main ou par un "exit(x)". Le "x" peut avoir 3 valeurs : 0,
Un bouquin sur le C ?
En C standard on sort, d'une façon normale, du programme par un "return x"
dans le main ou par un "exit(x)". Le "x" peut avoir 3 valeurs : 0,
EXIT_SUCCESS et EXIT_FAILURE. Les 2 premières sont équivalentes. Il n'y a
pas d'autres codes possibles de façon standard.
Sous Unix, la valeur "x" est plus libre et vaut typiquement un nombre entre
0 et 255. La valeur n'est pas libre, même si c'est un "int" (là encore
typiquement 32 bits), par ce que vu du père, le "x" est un champ de bits
dont certains indiquent la mort du fils par un signal. Les macros pour
manipuler le "x" sont du type WEXITSTATUS (man 2 wait).
Ensuite si tu veux passer du texte il y a 2 flux standards : stdout et
stderr. Et là aussi, typiquement, on place les messages d'erreur dans
stderr.
Un bouquin sur le C ?
En C standard on sort, d'une façon normale, du programme par un "return x"
dans le main ou par un "exit(x)". Le "x" peut avoir 3 valeurs : 0,
EXIT_SUCCESS et EXIT_FAILURE. Les 2 premières sont équivalentes. Il n'y a
pas d'autres codes possibles de façon standard.
Sous Unix, la valeur "x" est plus libre et vaut typiquement un nombre entre
0 et 255. La valeur n'est pas libre, même si c'est un "int" (là encore
typiquement 32 bits), par ce que vu du père, le "x" est un champ de bits
dont certains indiquent la mort du fils par un signal. Les macros pour
manipuler le "x" sont du type WEXITSTATUS (man 2 wait).
Ensuite si tu veux passer du texte il y a 2 flux standards : stdout et
stderr. Et là aussi, typiquement, on place les messages d'erreur dans
stderr.
Un bouquin sur le C ?
En C standard on sort, d'une façon normale, du programme par un "return x"
dans le main ou par un "exit(x)". Le "x" peut avoir 3 valeurs : 0,
EXIT_SUCCESS et EXIT_FAILURE. Les 2 premières sont équivalentes. Il n'y a
pas d'autres codes possibles de façon standard.
Sous Unix, la valeur "x" est plus libre et vaut typiquement un nombre entre
0 et 255. La valeur n'est pas libre, même si c'est un "int" (là encore
typiquement 32 bits), par ce que vu du père, le "x" est un champ de bits
dont certains indiquent la mort du fils par un signal. Les macros pour
manipuler le "x" sont du type WEXITSTATUS (man 2 wait).
Ensuite si tu veux passer du texte il y a 2 flux standards : stdout et
stderr. Et là aussi, typiquement, on place les messages d'erreur dans
stderr.
Je pense qu'il parlait de codes d'erreur au retour des fonctions. Pas de
codes d'erreur de fin du programme. Surtout s'il travaille sur une
extension Ruby, donc une bibliothèque ...
Je pense qu'il parlait de codes d'erreur au retour des fonctions. Pas de
codes d'erreur de fin du programme. Surtout s'il travaille sur une
extension Ruby, donc une bibliothèque ...
Je pense qu'il parlait de codes d'erreur au retour des fonctions. Pas de
codes d'erreur de fin du programme. Surtout s'il travaille sur une
extension Ruby, donc une bibliothèque ...
Eric Levenez wrote:
Un bouquin sur le C ?
je vais m'en payer un, mais lequel ???
en tk ma consultation de divers site cité en référence me laisse
perplexe, bien des tutos sont peu fiables même quand leurs exemples
compilent.
sur le net, pour l'instant, je n'ai pas trouvé d'exemple d'alloc mem
pour un tableau qui soit vraiment probant.
le seul que j'ai trouvé a fait hurler Luc )))
En C standard on sort, d'une façon normale, du programme par un "return x"
dans le main ou par un "exit(x)". Le "x" peut avoir 3 valeurs : 0,
EXIT_SUCCESS et EXIT_FAILURE. Les 2 premières sont équivalentes. Il n'y a
pas d'autres codes possibles de façon standard.
aille ça m'embête cette version C standard j'aimerais mieux avoir Deux
codes d'exit
Sous Unix, la valeur "x" est plus libre et vaut typiquement un nombre entre
0 et 255. La valeur n'est pas libre, même si c'est un "int" (là encore
typiquement 32 bits), par ce que vu du père, le "x" est un champ de bits
dont certains indiquent la mort du fils par un signal. Les macros pour
manipuler le "x" sont du type WEXITSTATUS (man 2 wait).
en fait j'ai regardé de plus près ce dont j'ai besoin, j'ai deux cas qui
justifient un exit anormal:
- allocation mémoire pas OK => EXIT_FAILURE
- le cas où le path filé en entrée ne correspond à rien dans le file
system => inutile de continuer
Ensuite si tu veux passer du texte il y a 2 flux standards : stdout et
stderr. Et là aussi, typiquement, on place les messages d'erreur dans
stderr.
ouais, grosso-modo c'est un peu comme en shell.
Eric Levenez <news@levenez.com> wrote:
Un bouquin sur le C ?
je vais m'en payer un, mais lequel ???
en tk ma consultation de divers site cité en référence me laisse
perplexe, bien des tutos sont peu fiables même quand leurs exemples
compilent.
sur le net, pour l'instant, je n'ai pas trouvé d'exemple d'alloc mem
pour un tableau qui soit vraiment probant.
le seul que j'ai trouvé a fait hurler Luc )))
En C standard on sort, d'une façon normale, du programme par un "return x"
dans le main ou par un "exit(x)". Le "x" peut avoir 3 valeurs : 0,
EXIT_SUCCESS et EXIT_FAILURE. Les 2 premières sont équivalentes. Il n'y a
pas d'autres codes possibles de façon standard.
aille ça m'embête cette version C standard j'aimerais mieux avoir Deux
codes d'exit
Sous Unix, la valeur "x" est plus libre et vaut typiquement un nombre entre
0 et 255. La valeur n'est pas libre, même si c'est un "int" (là encore
typiquement 32 bits), par ce que vu du père, le "x" est un champ de bits
dont certains indiquent la mort du fils par un signal. Les macros pour
manipuler le "x" sont du type WEXITSTATUS (man 2 wait).
en fait j'ai regardé de plus près ce dont j'ai besoin, j'ai deux cas qui
justifient un exit anormal:
- allocation mémoire pas OK => EXIT_FAILURE
- le cas où le path filé en entrée ne correspond à rien dans le file
system => inutile de continuer
Ensuite si tu veux passer du texte il y a 2 flux standards : stdout et
stderr. Et là aussi, typiquement, on place les messages d'erreur dans
stderr.
ouais, grosso-modo c'est un peu comme en shell.
Eric Levenez wrote:
Un bouquin sur le C ?
je vais m'en payer un, mais lequel ???
en tk ma consultation de divers site cité en référence me laisse
perplexe, bien des tutos sont peu fiables même quand leurs exemples
compilent.
sur le net, pour l'instant, je n'ai pas trouvé d'exemple d'alloc mem
pour un tableau qui soit vraiment probant.
le seul que j'ai trouvé a fait hurler Luc )))
En C standard on sort, d'une façon normale, du programme par un "return x"
dans le main ou par un "exit(x)". Le "x" peut avoir 3 valeurs : 0,
EXIT_SUCCESS et EXIT_FAILURE. Les 2 premières sont équivalentes. Il n'y a
pas d'autres codes possibles de façon standard.
aille ça m'embête cette version C standard j'aimerais mieux avoir Deux
codes d'exit
Sous Unix, la valeur "x" est plus libre et vaut typiquement un nombre entre
0 et 255. La valeur n'est pas libre, même si c'est un "int" (là encore
typiquement 32 bits), par ce que vu du père, le "x" est un champ de bits
dont certains indiquent la mort du fils par un signal. Les macros pour
manipuler le "x" sont du type WEXITSTATUS (man 2 wait).
en fait j'ai regardé de plus près ce dont j'ai besoin, j'ai deux cas qui
justifient un exit anormal:
- allocation mémoire pas OK => EXIT_FAILURE
- le cas où le path filé en entrée ne correspond à rien dans le file
system => inutile de continuer
Ensuite si tu veux passer du texte il y a 2 flux standards : stdout et
stderr. Et là aussi, typiquement, on place les messages d'erreur dans
stderr.
ouais, grosso-modo c'est un peu comme en shell.
Eric Levenez wrote:En C standard on sort, d'une façon normale, du programme par un "return x"
dans le main ou par un "exit(x)". Le "x" peut avoir 3 valeurs : 0,
Je pense qu'il parlait de codes d'erreur au retour des fonctions. Pas de
codes d'erreur de fin du programme.
Eric Levenez wrote:
En C standard on sort, d'une façon normale, du programme par un "return x"
dans le main ou par un "exit(x)". Le "x" peut avoir 3 valeurs : 0,
Je pense qu'il parlait de codes d'erreur au retour des fonctions. Pas de
codes d'erreur de fin du programme.
Eric Levenez wrote:En C standard on sort, d'une façon normale, du programme par un "return x"
dans le main ou par un "exit(x)". Le "x" peut avoir 3 valeurs : 0,
Je pense qu'il parlait de codes d'erreur au retour des fonctions. Pas de
codes d'erreur de fin du programme.
je vais m'en payer un, mais lequel ???
Prends déjà le premier cité dans la FAQ §3.9/
en tk ma consultation de divers site cité en référence me laisse
perplexe, bien des tutos sont peu fiables même quand leurs exemples
compilent.
sur le net, pour l'instant, je n'ai pas trouvé d'exemple d'alloc mem
pour un tableau qui soit vraiment probant.
le seul que j'ai trouvé a fait hurler Luc )))
Il n'y a pas que Luc pour hurler sur ta façon d'appréhender la programmation
et le langage C. :-/
je vais m'en payer un, mais lequel ???
Prends déjà le premier cité dans la FAQ §3.9/
en tk ma consultation de divers site cité en référence me laisse
perplexe, bien des tutos sont peu fiables même quand leurs exemples
compilent.
sur le net, pour l'instant, je n'ai pas trouvé d'exemple d'alloc mem
pour un tableau qui soit vraiment probant.
le seul que j'ai trouvé a fait hurler Luc )))
Il n'y a pas que Luc pour hurler sur ta façon d'appréhender la programmation
et le langage C. :-/
je vais m'en payer un, mais lequel ???
Prends déjà le premier cité dans la FAQ §3.9/
en tk ma consultation de divers site cité en référence me laisse
perplexe, bien des tutos sont peu fiables même quand leurs exemples
compilent.
sur le net, pour l'instant, je n'ai pas trouvé d'exemple d'alloc mem
pour un tableau qui soit vraiment probant.
le seul que j'ai trouvé a fait hurler Luc )))
Il n'y a pas que Luc pour hurler sur ta façon d'appréhender la programmation
et le langage C. :-/
Hamiral wrote:Je pense qu'il parlait de codes d'erreur au retour des fonctions. Pas de
codes d'erreur de fin du programme. Surtout s'il travaille sur une
extension Ruby, donc une bibliothèque ...
exact car ce que retourne ma fonction c'est un instance d'objet ruby ça
me donne une idée : en cas d'une erreur imparable (pb alloc mémoire) je
retourne Qnil, ça a l'avantage d'interdire à l'utilisateur de continuer
d'utiliser cette instance d'objet.
dans ce cas j'envoie sur stderr un message en clair.
dans les autres cas le prog se termine normalement avec un errno != 0 et
un errmsg.
le cas où l'utilisateur a entré un path inexistant "physiquement" dans
le file system me pose problème.
en fait dans mon prog C je n'ai qu'une fonction "réelle" les autres
étant des setters|getters (come on dit en Java) qu'on ne peut utiliser
qu'à condition d'avoir retourné un objet non null (Qnil en C ext to
ruby). je n'ai qu'une méthode singleton c'est #version.
donc (je réfléchis tout haut)
dans le cas d'un path inexistant, je peux
retourner un objet + un message d'erreur sur stderr car je souhaite
avoir le moins possible de sortie bloquante par exit(1).
reste à l'utilisateur de consulter #errno et #errmsg...
Hamiral <hamiral@hamham.fr> wrote:
Je pense qu'il parlait de codes d'erreur au retour des fonctions. Pas de
codes d'erreur de fin du programme. Surtout s'il travaille sur une
extension Ruby, donc une bibliothèque ...
exact car ce que retourne ma fonction c'est un instance d'objet ruby ça
me donne une idée : en cas d'une erreur imparable (pb alloc mémoire) je
retourne Qnil, ça a l'avantage d'interdire à l'utilisateur de continuer
d'utiliser cette instance d'objet.
dans ce cas j'envoie sur stderr un message en clair.
dans les autres cas le prog se termine normalement avec un errno != 0 et
un errmsg.
le cas où l'utilisateur a entré un path inexistant "physiquement" dans
le file system me pose problème.
en fait dans mon prog C je n'ai qu'une fonction "réelle" les autres
étant des setters|getters (come on dit en Java) qu'on ne peut utiliser
qu'à condition d'avoir retourné un objet non null (Qnil en C ext to
ruby). je n'ai qu'une méthode singleton c'est #version.
donc (je réfléchis tout haut)
dans le cas d'un path inexistant, je peux
retourner un objet + un message d'erreur sur stderr car je souhaite
avoir le moins possible de sortie bloquante par exit(1).
reste à l'utilisateur de consulter #errno et #errmsg...
Hamiral wrote:Je pense qu'il parlait de codes d'erreur au retour des fonctions. Pas de
codes d'erreur de fin du programme. Surtout s'il travaille sur une
extension Ruby, donc une bibliothèque ...
exact car ce que retourne ma fonction c'est un instance d'objet ruby ça
me donne une idée : en cas d'une erreur imparable (pb alloc mémoire) je
retourne Qnil, ça a l'avantage d'interdire à l'utilisateur de continuer
d'utiliser cette instance d'objet.
dans ce cas j'envoie sur stderr un message en clair.
dans les autres cas le prog se termine normalement avec un errno != 0 et
un errmsg.
le cas où l'utilisateur a entré un path inexistant "physiquement" dans
le file system me pose problème.
en fait dans mon prog C je n'ai qu'une fonction "réelle" les autres
étant des setters|getters (come on dit en Java) qu'on ne peut utiliser
qu'à condition d'avoir retourné un objet non null (Qnil en C ext to
ruby). je n'ai qu'une méthode singleton c'est #version.
donc (je réfléchis tout haut)
dans le cas d'un path inexistant, je peux
retourner un objet + un message d'erreur sur stderr car je souhaite
avoir le moins possible de sortie bloquante par exit(1).
reste à l'utilisateur de consulter #errno et #errmsg...
Hamiral wrote:
Je pense qu'il parlait de codes d'erreur au retour des fonctions. Pas de
codes d'erreur de fin du programme. Surtout s'il travaille sur une
extension Ruby, donc une bibliothèque ...
exact car ce que retourne ma fonction c'est un instance d'objet ruby ça
me donne une idée : en cas d'une erreur imparable (pb alloc mémoire) je
retourne Qnil, ça a l'avantage d'interdire à l'utilisateur de continuer
d'utiliser cette instance d'objet.
dans ce cas j'envoie sur stderr un message en clair.
dans les autres cas le prog se termine normalement avec un errno != 0 et
un errmsg.
le cas où l'utilisateur a entré un path inexistant "physiquement" dans
le file system me pose problème.
Hamiral <hamiral@hamham.fr> wrote:
Je pense qu'il parlait de codes d'erreur au retour des fonctions. Pas de
codes d'erreur de fin du programme. Surtout s'il travaille sur une
extension Ruby, donc une bibliothèque ...
exact car ce que retourne ma fonction c'est un instance d'objet ruby ça
me donne une idée : en cas d'une erreur imparable (pb alloc mémoire) je
retourne Qnil, ça a l'avantage d'interdire à l'utilisateur de continuer
d'utiliser cette instance d'objet.
dans ce cas j'envoie sur stderr un message en clair.
dans les autres cas le prog se termine normalement avec un errno != 0 et
un errmsg.
le cas où l'utilisateur a entré un path inexistant "physiquement" dans
le file system me pose problème.
Hamiral wrote:
Je pense qu'il parlait de codes d'erreur au retour des fonctions. Pas de
codes d'erreur de fin du programme. Surtout s'il travaille sur une
extension Ruby, donc une bibliothèque ...
exact car ce que retourne ma fonction c'est un instance d'objet ruby ça
me donne une idée : en cas d'une erreur imparable (pb alloc mémoire) je
retourne Qnil, ça a l'avantage d'interdire à l'utilisateur de continuer
d'utiliser cette instance d'objet.
dans ce cas j'envoie sur stderr un message en clair.
dans les autres cas le prog se termine normalement avec un errno != 0 et
un errmsg.
le cas où l'utilisateur a entré un path inexistant "physiquement" dans
le file system me pose problème.
dans ce cas j'envoie sur stderr un message en clair.
Oui, une fonction peut afficher sur stderr un message d'erreur, mais
une fonction générique n'affiche rien. C'est le programme appelant qui
fait l'affichage;
dans ce cas j'envoie sur stderr un message en clair.
Oui, une fonction peut afficher sur stderr un message d'erreur, mais
une fonction générique n'affiche rien. C'est le programme appelant qui
fait l'affichage;
dans ce cas j'envoie sur stderr un message en clair.
Oui, une fonction peut afficher sur stderr un message d'erreur, mais
une fonction générique n'affiche rien. C'est le programme appelant qui
fait l'affichage;