return et exit, comment les utiliser proprement ? + parsage d'adresse ethernet

**Freed0** · 14/05/2007, 18h11

Salut

Bon voilà, j'aimerais bien quelques conseils de votre part...

Tout d'abord, j'aimerais savoir comment bien utiliser les outils permettant de sortir d'une fonction, j'entend par là return et exit().

Pour le moment, je travaille de cette manière :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
int
ma_fonction_exemple(void)
{
    FILE *fp = NULL;
    /* Valeur de retour */
    int ret_value = EXIT_SUCCESS;
 
    /* Appels de fonctions, etc. Par exemple : */
    fp = fopen("monfichier.dat", "rb");
 
    if(fp != NULL)
    {
        /* Traitement */
 
        fclose(fp);
    }
    else
    {
        fprintf(stderr, "Erreur !");
        ret_value = EXIT_FAILURE;
    }
 
    return ret_value;
}

Le seul inconvénient que je trouve actuellement à cette méthode est que l'on s'y perd assez rapidement, et que ça peut devenir assez pénible à décoder dans certains cas...

Parcontre il m'est souvent arrivé de lire ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
int
ma_fonction_exemple(void)
{
    FILE *fp = NULL;
 
    /* Appels de fonctions, etc. Par exemple : */
    fp = fopen("monfichier.dat", "rb");
 
    if(fp == NULL)
    {
        fprintf(stderr, "Erreur !");
        return EXIT_FAILURE;
        /* Je retrouve aussi la forme suivante :
        exit(-1);
        */
    }
 
    /* Traitement */
 
    fclose(fp);
 
    return EXIT_SUCCESS;
}

Est-ce que cette dernière méthode est conseillée/propre ? L'utilisez-vous ? Si oui, pourquoi ?

Ensuite, j'aimerais votre avis sur la fonction suivante :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
int
get_hw_addr(struct ether_addr *mac, char *s)
{
    char    *p = NULL;
    char    delim[] = ":";
    int     ret_value = EXIT_SUCCESS;
    int     i = 0;
 
    /* Premier octet */ 
    p = strtok(s, delim);
 
    if(p != NULL)
        mac->octet[i] = (u_char)strtol(p, NULL, 16);
    else
        ret_value = EXIT_FAILURE;
 
    i++;
 
    /* 5 octets suivants */
    while(i < 6 && p != NULL)
    {
        p = strtok(NULL, delim);
 
        if(p != NULL)
            mac->octet[i] = (u_char)strtol(p, NULL, 16);
        else
            ret_value = EXIT_FAILURE;
 
        i++;
    }
 
    return ret_value;
}

C'est une fonction qui découpe la chaine de caractère fournie en paramètre en adresse ethernet. Ce résultat est stocké sous la forme d'une struct ether_addr (dont j'ai imité la forme, car je travaille sous Windows).

Pour le moment, j'ai quelques problèmes : je ne sais pas comment repérer toutes les erreurs qui pourraient intervenir... Par exemple si on utilise une lettre ne faisait pas partie de l'intervalle hexadécimal, strtol renvoie 0, et donc mon adresse ethernet comportera l'octet 0, ce qui n'était pas voulu...

Je voudrais aussi savoir si mon utilisation de strtok est correcte ?

Merci d'avance pour vos conseils

Fred

**souviron34** · 14/05/2007, 18h28

pour le if ( .. == NULL ) else..

en gros les 2 formes sont absolument corrrectes..

Tout dépend du volume de code et du volume de la fonction.... En fait c'est beaucoup plus pour faciliter la lecture/maintenance qu'autre chose.

Donc, suivant les cas, c'est l'un ou l'autre...

Dans le cas que tu présentes, j'aurais tendance à préférer la 2ième solution, car il peut y avoir beaucoup de code de traitement, et donc avoir tout un grand paragraphe indenté, avec éventuellement des indendations à l'intérieur, est plus complexe à lire.

En ce qui concerne le problème exit/return, là encore ça dépend de l'utilisation. Pour un programme devant être "safe-proof", c'est à dire ne quittant jamais, il est évident que le return est à utiliser, avec traitements appropriés en sortie (même si c'est qu'une allocation de mémoire n'a pu se faire). Par contre, dans le cas de programmes généraux, ne nécessitant pas une robustesse de running-time, le mieux est de faire des exit lorsqu'on rencontre une erreur du style fatal (allocation échoue, fichier non trouvé, etc..).

Enfin, en ce qui concerne ton 3ième problème, je rajouterais à ce compte-là dans le if ( p != NULL ) une boucle testant sur la longueur de p la validité des caractères, avant de faire le strtol...

**Skyounet** · 14/05/2007, 18h57

Certaines personnes ici sont partisanes du "un seul return par fonction"...

Moi je prefère plusieurs return, parce que sinon je trouve que l'on accumule les imbrications (if(* != NULL)...) et ça devient vite illisible.

Juste un avis personnel.

**Emmanuel Delahaye** · 14/05/2007, 23h34

Envoyé par Freed0

Pour le moment, je travaille de cette manière :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
int
ma_fonction_exemple(void)
{
    FILE *fp = NULL;
    /* Valeur de retour */
    int ret_value = EXIT_SUCCESS;
 
    /* Appels de fonctions, etc. Par exemple : */
    fp = fopen("monfichier.dat", "rb");
 
    if(fp != NULL)
    {
        /* Traitement */
 
        fclose(fp);
    }
    else
    {
        fprintf(stderr, "Erreur !");
        ret_value = EXIT_FAILURE;
    }
 
    return ret_value;
}

Le seul inconvénient que je trouve actuellement à cette méthode est que l'on s'y perd assez rapidement, et que ça peut devenir assez pénible à décoder dans certains cas...

Personnellement j'écris ça comme ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
int ma_fonction_exemple (void)
{
   int err = 0;
   FILE *fp = fopen ("monfichier.dat", "rb");
 
   if (fp != NULL)
   {
      /* Traitement */
 
      fclose (fp), fp = NULL;
   }
   else
   {
      fprintf (stderr, "Erreur !\n");
      err = 1;
   }
 
   return err;
}

ce qui est plus clair à mon sens...

Je n'ai, en principe, pas de bonne raison de faire autrement.

**Emmanuel Delahaye** · 15/05/2007, 00h06

Envoyé par Freed0

Je voudrais aussi savoir si mon utilisation de strtok est correcte ?

Pas besoin de strtok() :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
 
#include <stdlib.h>
#include <stdio.h>
#include <assert.h>
 
struct ether_addr
{
   unsigned char octet[6];
};
 
int get_hw_addr (struct ether_addr *mac, char const *s)
{
   int err = 0;
   char const *pend = s;
   int delim = ':';
   size_t i = 0;
 
   while (!err && *pend != 0 && i < sizeof mac->octet / sizeof *mac->octet)
   {
      /* ce cast est du a une incoherence dans la specification de strtoul(). */
      unsigned n = strtoul (pend, (char **) &pend, 16);
 
      err = *pend != delim && *pend != 0;
 
      if (!err)
      {
         pend++;
         err = n > 255;
         if (!err)
         {
            mac->octet[i] = n;
            i++;
         }
      }
   }
   return err;
}
 
int main (void)
{
 
   struct ether_addr mac;
   int err = get_hw_addr (&mac, "12:34:56:78:9A:BC");
 
   if (!err)
   {
      size_t i;
      for (i = 0; i < sizeof mac.octet / sizeof *mac.octet; i++)
      {
         if (i == 0)
            printf ("%02X", mac.octet[i]);
         else
            printf (":%02X", mac.octet[i]);
 
      }
      printf ("\n");
   }
   else
      puts ("error");
   return 0;
}

**Médinoc** · 15/05/2007, 10h25

exit() ne sort pas de la fonction courante, mais de tout le processus, et selon moi ne peut être utilisée correctement (surtout en C++, même si là on est en C).

return sort assez proprement de la fonction courante, et le problème est plus de l'utiliser lisiblement, en C comme en C++.

**Freed0** · 20/05/2007, 00h04

Bon, je détère mon topic. En passant, merci pour vos réponses (j'avais pas pensé à revenir poster

).

Donc j'aimerais juste votre avis sur ce warning :

Code :

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

1
2
3
wol.c: In function 'main':
wol.c:29: warning: missing initializer
wol.c:29: warning: (near initialization for 'to.sin_port')

Voici la ligne concernée :

Code :

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

1
2
3
28:  struct ether_addr    ether = {{0}};
29:  struct sockaddr_in   to = {0};
30:  unsigned char        packet[102] = {0};

Et enfin les options utilisées pour la compilation (chippées chez Emmanuel) :

Code :

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

gcc -Wall -Wextra -O2 -Wwrite-strings -Wstrict-prototypes

Ensuite, j'aimerais votre avis sur ce code. Toutes les remarques (fondées) sont les bienvenues. Problèmes, améliorations intéressantes, etc.
Voici le fichier en question : http://myspace.voo.be/tjacquelin/src/wol.c

Merci

**Emmanuel Delahaye** · 20/05/2007, 01h54

Envoyé par Freed0

Donc j'aimerais juste votre avis sur ce warning :

Code :

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

1
2
3
wol.c: In function 'main':
wol.c:29: warning: missing initializer
wol.c:29: warning: (near initialization for 'to.sin_port')

Tu peux ignorer.

**Freed0** · 20/05/2007, 11h27

Envoyé par Emmanuel Delahaye

Tu peux ignorer.

Je suppose que je peux aussi enlever les doubles accolades de la ligne 28 alors ? Elle génèrent le même type de warning...

**Emmanuel Delahaye** · 20/05/2007, 11h39

Envoyé par Freed0

Je suppose que je peux aussi enlever les doubles accolades de la ligne 28 alors ? Elle génèrent le même type de warning...

As-tu compris le warning ? Ce ne sont pas les accolades qui génèrent le warning, mais le fait qu'il manque des initialisateurs, ce qui n'est pas une erreur en soi, car les autres champs sont automatiquement mis à 0. C'est un peu trop de zèle de la part de gcc, qui est difficilelment débrayable (fait partie de -Wall ou de -Wextra, je ne sais plus).

Il y a bien le mode parano (sur mon site, section codage), où je mets les flags 'à la main' (et où, par conséquent, je n'active pas celui qui fait ce warning), mais il est un peu violent sur d'autres points et certains headers de MinGW doivent être modifiés... Pas pour les débutants, mais si tu sais ce que tu fais, pas de problèmes.

**Freed0** · 20/05/2007, 11h44

Envoyé par Emmanuel Delahaye

As-tu compris le warning ? Ce ne sont pas les accolades qui génèrent le warning, mais le fait qu'il manque des initialisateurs, ce qui n'est pas une erreur en soi, car les autres champs sont automatiquement mis à 0. C'est un peu trop de zèle de la part de gcc, qui est difficilelment débrayable (fait partie de -Wall ou de -Wextra, je ne sais plus).

J'ai compris le warning. L'autre warning donc je parle est :

Code :

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

wol.c:28: warning: missing braces around initializer

Cependant, ces 2 lignes sont toutes les 2 correctes non ?

Code :

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

1
2
3
28:  struct ether_addr    ether = {{0}};
ou
28:  struct ether_addr    ether = {0};

**Emmanuel Delahaye** · 20/05/2007, 12h26

Envoyé par Freed0

J'ai compris le warning. L'autre warning donc je parle est :

Code :

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

wol.c:28: warning: missing braces around initializer

Cependant, ces 2 lignes sont toutes les 2 correctes non ?

Code :

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

1
2
3
28:  struct ether_addr    ether = {{0}};
ou
28:  struct ether_addr    ether = {0};

Oui. Mais tu auras plus de warnings avec le 2ème, comme tu l'as remarqué...

**Freed0** · 20/05/2007, 13h16

Bon, je ne pouvais pas ne pas tester le mode parano

Un warning, que je comprend pas trop... :

Code :

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

1
2
src/main.c: In function 'main':
src/main.c:96: warning: will never be executed

Voici la ligne en question :

Code :

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

1
2
3
95:  to.sin_family = AF_INET;
96:  to.sin_port = htons (9);
97:  if ((err ...

Pourquoi cette ligne ne serait-elle pas executée ? Si je la commente, le warning disparait. Et pourtant, la ligne est bel et bien prise en compte, ça si je change le port, Ethereal me l'indique...

**Emmanuel Delahaye** · 20/05/2007, 13h22

Envoyé par Freed0

Bon, je ne pouvais pas ne pas tester le mode parano

Un warning, que je comprend pas trop... :

Code :

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

1
2
src/main.c: In function 'main':
src/main.c:96: warning: will never be executed

Voici la ligne en question :

Code :

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

1
2
3
95:  to.sin_family = AF_INET;
96:  to.sin_port = htons (9);
97:  if ((err ...

Pourquoi cette ligne ne serait-elle pas executée ? Si je la commente, le warning disparait. Et pourtant, la ligne est bel et bien prise en compte, ça si je change le port, Ethereal me l'indique...

Oui, quelques défauts de ce genre on déjà été signalés... C'est peut être un bug de gcc. Rapport de bug ?

**Freed0** · 20/05/2007, 13h58

Bon allez, encore une question :

J'ai ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
ssize_t  sent = 0;
 
...
 
sent = sendto (sockfd, packet, sizeof packet, 0, (struct sockaddr *) &to, sizeof to);
 
if (sent < sizeof packet)
{
    /* Erreur ... */
}

Je compare un entier signé avec un non-signé => warning...

J'ai casté le sizeof packet avec un (signed), mais j'ai l'impression que ça fait un peu bricolage. Y'a une autre méthode ou c'est OK ?

**Emmanuel Delahaye** · 20/05/2007, 14h04

Envoyé par Freed0

Bon allez, encore une question :

J'ai ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
ssize_t  sent = 0;
 
...
 
sent = sendto (sockfd, packet, sizeof packet, 0, (struct sockaddr *) &to, sizeof to);
 
if (sent < sizeof packet)
{
    /* Erreur ... */
}

Je compare un entier signé avec un non-signé => warning...

J'ai casté le sizeof packet avec un (signed), mais j'ai l'impression que ça fait un peu bricolage. Y'a une autre méthode ou c'est OK ?

C'est OK si tu as vérifié que sent n'était pas < 0...
Au fait c'est pas une erreur que sent soit < sizeof packet. Ca veut simplement dire que l'émission est incomplète et qu'il faut poursuivre. La taille des paquets est limitée (un peu plus que 1024 octets).

http://emmanuel-delahaye.developpez....eaux.htm#texte

**Freed0** · 20/05/2007, 14h08

Envoyé par Emmanuel Delahaye

C'est OK si tu as vérifié que sent n'était pas < 0...
Au fait c'est pas une erreur que sent soit < sizeof packet. Ca veut simplement dire que l'émission est incomplète et qu'il faut poursuivre. La taille des paquets est limitée (un peu plus que 1024 octets).

http://emmanuel-delahaye.developpez....eaux.htm#texte

Dans mon cas, le packet fait 102 octets (magic packet). Donc je traite les 2 cas de la même façon.
Je pourrais même uniquement tester le -1 non ? Y a-t-il des cas où le buffer serait inférieur à 102 octets

?

**Emmanuel Delahaye** · 20/05/2007, 14h12

Envoyé par Freed0

Dans mon cas, le packet fait 102 octets (magic packet). Donc je traite les 2 cas de la même façon.
Je pourrais même uniquement tester le -1 non ? Y a-t-il des cas où le buffer serait inférieur à 102 octets

?

On ne doit faire aucune hypothèse sur la taille des buffers. C'est à l'application de faire le découpage en fonction de la valeur retournée par la fonction d'émission.

Tu n'as pas lu mon article ? Je parle aux murs ou quoi ?

**Freed0** · 20/05/2007, 14h18

Envoyé par Emmanuel Delahaye

On ne doit faire aucune hypothèse sur la taille des buffers. C'est à l'application de faire le découpage en fonction de la valeur retournée par la fonction d'émission.

Tu n'as pas lu mon article ? Je parle aux murs ou quoi ?

J'avais en effet zappé cette partie de l'article.
Je m'en vais créer une fonction qui gère un envoi.

PS :
En lisant la partie sur les Emissions de blocs (cas général), j'ai relevé 2 petites fautes d'orthographes :
"A nous de créer un algorithme qui tient compte de se résultat et envoi la suite des données."