Discussion :

[Anthony_CTI]

Bonjour,

Je cherche à faire tourner un premier programme supposé ultra-simple à l'aide de Flex et Bison.

Mon problème: Mon expression régulière renseignée dans la première partie du fichier Flex ne fonctionne pas.

Voici les fichiers Flex, Bison, et le header nécessaires à la compilation de l'executable:

Le fichier.l,

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
%{
#include "global.h"
#include "calculatrice.h"
#include <stdlib.h>
%}
 
chiffre	[0-9]
 
%%
{chiffre}	return(CHIFFRE);
"+"			return(PLUS);
"9"			return(CHIFFRE9);
%%

Le fichier.y

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
%{
 
#include "global.h"
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
 
%}
 
%token  CHIFFRE
%token  CHIFFRE9
%token  PLUS
%token  FIN
 
%start Input
%%
 
Input:/* Vide */
  | Input CHIFFRE9 { printf ("chiffre 9");}
  | Input CHIFFRE { printf ("chiffre");}
  | Input PLUS { printf ("symbol +");}
  ;
 
%%
 
int yyerror(char *s) {
  printf("%s\n",s);
}
 
int main(void) {
  yyparse();
}

le fichier.h

Code :

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

1
2
#define YYSTYPE double
extern YYSTYPE yylval;

En plus, voici les commandes utiles pour générer l'executable.

Code :

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

1
2
3
4
5
6
7
8
9
 
flex fichier.l;
mv lex.yy.c fichier_lex.c;
bison -y -d fichier.y;
mv y.tab.c fichier_yy.c;
mv y.tab.h fichier.h;
gcc -c fichier_lex.c;
gcc -c fichier_yy.c;
gcc -o calc fichier_lex.o fichier_yy.o -ll -lm;

Constat: Lorsque je fais tourner l'exécutable, si je rentre un "+" ou un "9", je vais bien faire mon affichage en retour càd "symbol +" ou "chiffre 9". En revanche, si je rentre un chiffre entre 0 et 9, le programme se contente de me renvoyer ce chiffre sans imprimer "chiffre" comme je semble vouloir le faire. La différence entre mes entrées "+" ou "9" et l'ensemble des chiffres de 0 à 9 est que j'ai utilisé une expression régulière pour la deuxième. Cette dernière ne semble pas fonctionner...

Pourquoi ?

Merci beaucoup

Anthony Brézillon

[Obsidian]

Bonjour,

Es-tu sûr que le programme que tu nous présentes est exactement le même que celui que tu fais tourner, car chez moi l'expression régulière est bien reconnue. Cela dit, il y a plusieurs imprécisions dans ton programme qui conduiront fatalement à des bugs difficiles à déceler. Par exemple :

— Il faut mettre les #include <> avant les #include "". Sinon, ce qui est défini dans les seconds risquent de manquer d'information, d'une part, et de perturber ce qui doit l'être dans les premiers, d'autre part ;
— Les parenthèses après « return » ne servent à rien. Mais ça, ce n'est qu'un détail ;
— La récursivité à gauche risque de te poser des problèmes un peu plus tard ;
— "9" est déjà inclus dans [0-9] et, en principe, c'est cette expression qui devrait reconnaître entièrement le chiffre « 9 » et être validée avant l'expression "9". Il faudra que tu permutes ces deux règles quand tu auras résolu ton premier problème.

Maintenant, le fait de voir apparaître le caractère sans le contenu de ton printf() associé signifie que le lexer est tombé dans son comportement par défaut : aucune règle n'a reconnu ton caractère, il est donc renvoyé tel quel vers la sortie standard sans remonter à Yacc.

Pourquoi ? Mystère, effectivement.

[Anthony_CTI]

Merci pour ta réponse.

J'ai (re)créé l'exécutable de mon côté uniquement à partir des infos que j'ai données dans mon premier message. Il est donc certain que je manipule les même fichiers. Le problème persiste...

Par la suite, j'ai fait certaines modifs que tu m'as recommandées. Mon expression régulière n'est toujours pas reconnue...

Utilises-tu les même outils et commandes de compilation que celles que j'ai renseignées dans mon premier message ?

Anthony

[Anthony_CTI]

Autre chose ,

peut-tu me mailer tes fichiers__yy.c et fichier_lex.c et fichier.h ?

Peut-être y trouverai-je des différences avec les miens.

Merci !

Anthony

[Anthony_CTI]

Bonjour,

Pour étoffer un peu et précisez mon problème: voici un fichier.l aussi simple que le précédent.

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
%{
#include <stdlib.h>
#include "global.h"
#include "fichier.h"
%}
 
lettre [a-zA-Z]
 
%%
{lettre}	return LETTRE;
{lettre}+	return MOT;
[0-9]		return CHIFFRE;
[0-9]+		return NOMBRE;
"+"			return PLUS;
r			return R;
r+			return RR;

Les CHIFFRE NOMBRE PLUS R et RR sont reconnus sans souci tandis que les LETTRE et MOT ne le sont pas. Voici un exemple d'utilisation du programme:

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
 
$ ./calc
5
chiffre
 
45
nombre
 
+
symbole +
 
p
p
fg
fg
r
lettre r
 
r45rr
lettre r
nombre
multiple lettre r

Voila, merci d'avance pour votre aide.

Anthony

[Obsidian]

C'est très curieux. Quelles versions de flex et de bison utilises-tu ? J'ai pour ma part GNU bison 2.4.1 et flex 2.5.35 (en plus, pour une raison inconnue, ma Fedora 13 ne propose que les versions statiques de liby et libfl).

Chez moi, ça fonctionne comme attendu. En plus, la lettre R et la suite RR sont reconnus respectivement comme une LETTRE et comme un MOT, si bien que R et RR ne sont jamais atteints, et flex est capable de s'en rendre compte à la compilation.

[Anthony_CTI]

Merci pour ces précisions,

De mon côté:

Flex: 2.5.35
Bison: 2.3-2

Utilisés sous redhat
version du noyau: 2.6.18-128

[Anthony_CTI]

correction: flex: 2.5-4

[Obsidian]

On utilise donc le même flex.

Je ne vois qu'une seule hypothèse : tu as inséré sans le savoir des espaces insécables quelque part dans tes déclarations. Quand je le fais, j'obtiens les mêmes résultats que toi.

Tu peux mettre tes fichiers en ligne quelque part tels quels, plutôt que les copier-coller ?

[Anthony_CTI]

fichier.l : http://dl.free.fr/oLAZwknsk

Les autres sont en attente.

[Anthony_CTI]

fichier.y: http://dl.free.fr/euiDERZke
global.h: http://dl.free.fr/qwRVVbyOJ

[Anthony_CTI]

Ok, le souci semble bien tourné autour de la mise en forme du texte !
Je ne sais pas si le problème vient de la présence d'un espace insécable mais ce qui est sûr, c'est qu'il vient de mon éditeur de texte (notepad++) .
Si j'utilise nedit, j'ai ce Warning à la compilation:

Code :

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

1
2
 
"fichier.l", line 15: warning, rule cannot be matched

probablement dû au fait que le même caractère se retrouve dans plusieurs expressions. Sans corriger ce warning, le programme fonctionne correctement comme tu l'as décrit dans ton dernier message !

Si j'utilise notepad, la compilation se passe sans warning mais les expressions régulières ne sont pas reconnues.

Pour ce test, j'ai aussi récupéré le code source à partir de mon premier message. Je suis donc à nouveau certain de n'avoir rien modifié à part l'éditeur de texte utilisé. Le souci (mineur désormais) est que j'aimerais bien pouvoir continuer à utiliser notepad++.

[Obsidian]

Ça fonctionne chez moi aussi avec les fichiers que tu as mis en ligne.

Ça pourrait aussi venir du fait que ton éditeur utilise des retours à la ligne type DOS « 0D 0A » et non Unix (« 0A » tout seul). Un petit coup de dos2unix sur les fichiers créés avec notepad++ devrait suffire à être fixé.

Cela dit, j'observe ce type de retour dans les fichiers que tu as mis en ligne et cela ne perturbe pas plus l'exécutable généré, qui fonctionne nominalement. Que donne la commande « locale » chez toi ?

Si j'utilise notepad, la compilation se passe sans warning mais les expressions régulières ne sont pas reconnues.

Oui, normal car, comme ton expression ne capture plus les lettres et les mots, toutes les règles peuvent de nouveau être atteintes.

[Anthony_CTI]

Voici le résultat de ma commande locale:

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
$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

[Anthony_CTI]

La commande dos2unix me permet de continuer à utiliser notepad++. Mon problème est résolu à 100%.

Merci pour cette aide précieuse.

Anthony

[Obsidian]

Mouais, ça ne me dit toujours pas pourquoi deux versions très proches voire identiques d'un même logiciel se formalisent pour des \r\n d'un côté (le tien) et pas de l'autre (le mien), mais soit.

Bon courage pour la suite.

[Anthony_CTI]

Tu veux dire que tu n'as pas les même warning que moi à la compilation à la compilation ?

[Obsidian]

Les warnings si, à ceci près qu'ils sont écrits en français (ce qui est normal étant donné que ma locale est fr_FR.

Ce qui m'étonne, c'est que, compilé chez moi, ton programme ne souffre pas des problèmes de retour à la ligne alors que ton code source est bien formaté dans le style D.O.S. (éditeur hexadécimal à l'appui).

Bon, peu importe.