[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gulliver] Python et la gestion des signaux


From Patrick Lamaizière <patgul+gul at davenulle dot org>
Subject Re: [gulliver] Python et la gestion des signaux
Date Sat, 12 Apr 2008 12:23:34 +0200

Le Thu, 10 Apr 2008 19:24:50 +0200,
Patrick Lamaizière <patgul+gul at davenulle dot org> a écrit :

> Tu as le serial programming howto (je sais pas si c'est à jour)
> http://www.faqs.org/docs/Linux-HOWTO/Serial-Programming-HOWTO.html

> Dans l'exemple "3.3. Asynchronous Input" il y a 3 bugs, ami lecteur
> les trouveras tu ?

Y'en a même 4 en fait :

while (STOP==FALSE) {
  printf(".\n");usleep(100000);
  /* after receiving SIGIO, wait_flag = FALSE, input is
  available and can be read */
  
  if (wait_flag==FALSE) { 
    res = read(fd,buf,255);
    buf[res]=0;
    printf(":%s:%d\n", buf, res);
    if (res==1) STOP=TRUE; /* stop loop if only a CR was input */
    wait_flag = TRUE;      /* wait for new input */ }
}

Le premier c'est un débordement de buf si read() lit 255
caractères, buf[255] n'a alors pas la place pour buf[res]=0.

Le second c'est que "by design" ça ne marche pas. Le gestionnaire de
signal met un drapeau à FALSE, mais il y a toujours une fenêtre de temps
entre le moment où il est testé dans le programme principal et le
moment où il est remis à true par celui ci. Si dans cette fenêtre de
temps un signal SIGIO est reçu il n'est pas pris en compte.

Le troisième c'est que printf() n'est pas autorisé dans un gestionnaire
de signal. La liste des fonctions "saines" est donnée dans man
sigaction

Enfin errno n'est pas sauvegardée dans le gestionnaire. printf n'a pas
l'air de changer errno mais c'est une bonne pratique de le faire. Ça
permet d'éviter des nervous breakdown comme on dit de nos jours.