FR 3018368 A1 20150911 FR 1451922 A 20140310 3018368 PROCEDE ET DISPOSITIF POUR GERER LES AMBIGÜITES DANS L'ANALYSE D'UN CODE SOURCE Domaine de l'invention L'invention concerne le domaine de la compilation de code source et en particulier porte sur un procédé et un dispositif pour gérer les ambigüités dans l'analyse du code source. Etat de la Technique Pour transformer le code source d'un programme informatique écrit dans un langage source en un code objet dans un langage cible, les compilateurs effectuent en première phase des opérations d'analyse au travers de trois principaux composants. Les étapes d'analyse incluent en général, une première étape d'analyse lexicale opérée par un analyseur lexical, aussi connu sous l'appellation 'scanner', qui décompose le code source en entités lexicales appelées jetons (« tokens » selon l'anglicisme consacré). Les jetons sont ensuite utilisés par un analyseur syntaxique (« parser » en anglais) pour identifier la structure syntaxique du programme. Une structure en arbre syntaxique est en général construite à partir des jetons selon une grammaire qui définit la syntaxe du langage. Un analyseur sémantique permet de compléter l'arbre syntaxique et de produire une table de symboles qui contient les définitions des symboles du code source. L'arbre issu de la chaîne d'analyse est ensuite utilisé par d'autres composants du compilateur pour générer le code cible. La grammaire associée à un compilateur de langage C a été définie par l'Organisation Internationale de Standardisation (ISO en anglais) selon la norme ISO/IEC 9899:1999 pour spécifier entre autres la 2 301 836 8 syntaxe et les règles sémantiques du langage C. Cette norme a évoluée et est référencée actuellement comme ISO/IEC 9899 :2011. La grammaire du langage C définie dans cette norme introduit des ambiguïtés dans l'analyse syntaxique du langage quant aux symboles 5 que l'on retrouve dans les déclarations connues «typedef-name» et « identifier » référencées dans la norme au chapitre « 6.7.8 ISO/IEC 9899:2011 ». En effet, la grammaire d'un langage de programmation tel que le langage C est un ensemble comprenant des symboles et des règles de 10 production. Les symboles sont de deux sortes : « symbole terminal » correspondant à une entité lexicale du langage, et « symbole non-terminal ». Un des symboles non-terminal est désigné comme le point de départ de la grammaire. Une règle de production définit de quelle manière une suite de symboles appartenant à la grammaire peut correspondre à 15 un nouveau symbole. L'analyse syntaxique consiste alors à construire un arbre à partir d'un code source décomposé en entités lexicales, arbre communément appelé arbre de parse dont le sommet est le symbole de départ de la grammaire, les feuilles sont les symboles terminaux, et dont chaque noeud est créé par l'application des règles de production. 20 Ainsi la grammaire du langage C permet de définir les éléments syntaxiques du langage comme des instructions, via les symboles de la grammaire, et de définir le rôle des différents éléments lexicaux (ponctuation, noms) dans la constitution de phrases correctes, via les règles de production de la grammaire. Cette grammaire, comme énoncé 25 plus haut est ambiguë, et peut, pour une même séquence de caractères telle la séquence «a * a», aboutir à plusieurs constructions différentes. Par exemple, l'élément syntaxique nommé « déclaration » peut se confondre avec l'élément nommé «expression », les deux éléments n'ayant pourtant pas du tout la même signification. En effet, une 3 « déclaration » consiste à définir un « symbole » dans le programme et lui associer un « type », c'est à dire une information décrivant les données associées ou désignées par ce symbole telles des valeurs numériques (entières, réelles, etc ...), du texte ou des éléments composites (complexes). Dans la grammaire, on trouve alors des éléments « déclaration » ayant une partie gauche correspondant à une « description de type », et une partie droite correspondant à un « nom de symbole », le tout constituant communément une association « type/symbole ». Cependant, il existe une exception à l'association type/symbole pour les déclarations dont la description est « typedef », et dont le nom de symbole est « typedef-name ». Un tel nom de symbole ne peut apparaitre dans le reste du code source que soit dans une autre description de type, soit dans la partie droite d'une autre déclaration. Hormis cette exception, un tel symbole ne peut que se trouver dans une description de type. Il est possible sous certaines conditions de redéfinir un symbole, et lui associer une description de type différente. Il est ainsi tout à fait envisageable de redéfinir un symbole « typedef-name » en un symbole d'un autre type. Par exemple, la suite de caractères suivante : « a * a » peut s'interpréter comme une « déclaration » ayant pour description de type la partie gauche « a * » et pour définition de symbole la partie droite « a », si l'élément « a » a été précédemment définit comme symbole "typedef-name". Cependant, si le symbole « a » n'a pas été précédemment défini comme « typedef-name », cette même phrase « a * a » rencontrée dans le code, peut prendre un sens tout différent, et être une expression qui décrit un calcul, en l'occurrence la multiplication de la valeur représentée par « a » par elle-même. Il existe des solutions pour permettre de gérer ces ambigüités. 4 3018368 Une approche consiste de manière systématique à contextualiser l'analyseur lexical, l'analyseur syntaxique et l'analyseur sémantique en leur associant une mémoire pour enregistrer les définitions des symboles dans une table appelée table des symboles. 5 Le principe de contextualisation opère suivant le découpage fonctionnel suivant : - l'analyseur sémantique identifie la définition d'un symbole et la description de type associée à ce symbole et l'enregistre dans la table des symboles ; 10 - lors de la rencontre d'un nom (par exemple «a») dans le code source entrant, l'analyseur lexical interroge la table des symboles pour déterminer si le nom a déjà été défini et de quelle nature. Si le nom rencontré est déjà défini comme « typedef-name », l'élément lexical est associé à un jeton « typedef-name » sinon l'élément 15 lexical est associé à un jeton « identifier ». Cependant cette approche implique que la règle listée dans la norme ISO/IEC 9899:2011 au chapitre en 6.7.8 soit retirée de la grammaire: typedef-name: 20 identifier et que le symbole « typedef-name » devienne un symbole terminal de la grammaire, c'est à dire un jeton produit par l'analyseur lexical. Sur la base de cette modification, différentes implémentations d'analyseurs C, que ce soit des compilateurs ou des outils d'analyse ont 25 vu le jour. Un premier type d'implémentation consiste à étendre la grammaire de la norme C et permettre l'apparition de jetons « typedef-name » issus 5 de l'analyse lexicale contextuelle. Ceci vise à rendre syntaxiquement correcte la déclaration «a * a » dans le cas où 'a' est un jeton « typedefname ». Cette implémentation dite d'une grammaire étendue est utilisée dans des compilateurs existants tels `GCC' (GNU Compiler Collection) dans les versions antérieures à la V4.0 ou 'PCC' (Portable C Compiler) et est aussi utilisée dans des outils d'analyse de C tels les outils 'CIL' (C Intermediate Language), `Frama-C' ou encore `FrontC'. Or, la grammaire de la norme C n'autorise que la génération de jetons « identifier » dans une déclaration, et réaliser une grammaire étendue est une opération 10 complexe présentant un risque élevé d'introduire de nouvelles ambiguïtés. Un autre inconvénient, est qu'une grammaire étendue est significativement plus longue que la grammaire de la norme C, augmentant ainsi la complexité de l'analyse syntaxique. En effet, une fois 15 une grammaire étendue obtenue, le développement d'un analyseur consiste à générer l'implémentation de l'analyseur syntaxique par un générateur de compilateur tels les compilateurs par exemple 'Berkeley ou AT&T YACC', `GNU bison' ou encore `USF ANTLR'. C'est le générateur qui prend en charge le développement du reste de l'analyseur syntaxique 20 et assure que le comportement de l'analyseur syntaxique ainsi implémenté et son interaction avec l'analyseur lexical et avec l'analyseur sémantique est conforme à la grammaire. Un autre type d'implémentation consiste à abandonner la grammaire de la norme C et à réécrire à la main l'analyseur syntaxique, 25 par exemple en langage C ou C++. Cette technique, dite de l'analyseur syntaxique récursif descendant car elle suppose un certain type d'analyseur, présente les inconvénients de ne fonctionner de manière simple, que pour une classe plus réduite de grammaires, dont la grammaire de C ne fait pas partie. L'analyseur syntaxique ainsi développé 30 est généralement très complexe, tant en taille de code qu'en 6 3018368 comportement, et ne bénéficie d'aucune garantie de conformité, si ce n'est en tant que transcription manuelle élément par élément, de la norme du langage analysé. De plus, il requière une coûteuse procédure de test, qui ne garantit pas pour autant une conformité complète. Des outils 5 utilisant cette technique sont par exemple `GNU GCC' à partir de la version 4.0 ou 'Apple CLANG'. Un autre type d'implémentation connue consiste à considérer qu'une analyse partielle du code source est suffisante pour les buts de l'implémentation, et qu'une résolution complète du problème de l'ambigüité est alors inutile. Dans ce cas, l'analyseur syntaxique est considéré comme incapable de valider l'intégralité des syntaxes correctes, mais il est capable de réajuster via des stratégies ad-hoc lorsqu'il rencontre une ligne ambiguë. Des outils comme `LIP6 Coccinelle' ou des outils de réingénierie de code utilisent cette approche, leurs objectifs se satisfaisant d'une analyse syntaxique partielle du code source. Une telle approche n'est pas appropriée pour un outil de compilation. Ainsi les solutions connues présentent des inconvénients et ne répondent pas au besoin d'exploiter sans changement une grammaire 20 normée dans un compilateur de code source. Il existe alors le besoin de fournir un dispositif et un procédé pour gérer les ambigüités relatives aux déclarations de symboles pour une grammaire normée. L'invention proposée permet de répondre à ce besoin. 25 Résumé de l'invention 7 Un objet de la présente invention est de proposer un procédé qui exploite une grammaire normée sans la modifier ni avoir recours à une grammaire étendue pour gérer les ambigüités des déclarations de symboles. Le dispositif de la présente invention permet à l'analyseur lexical de générer des jetons sélectifs différentiant les entités lexicales ambigües ou multivoques. Les avantages techniques de la présente invention sont de réduire significativement la complexité d'un analyseur syntaxique, tant en terme de coût de développement logiciel grâce à une taille de code plus réduite, qu'en terme de sa validation car il assure un respect au plus près de la norme et non une revalidation d'extensions qui ne seraient pas définies dans la norme. Un autre objet de la présente invention est de proposer un procédé 15 permettant d'activer au sein de l'analyseur lexical un indicateur de différentiation des jetons émis. Avantageusement, l'invention trouvera application pour des compilateurs de code source et des analyseurs du langage de programmation C, ainsi que ses extensions. En particulier, l'invention 20 s'applique au domaine des outils de développement et d'analyse, des compilateurs et des outils de vérification de code pour la sûreté et l'ingénierie du logiciel. Pour obtenir les résultats recherchés, un dispositif, un procédé et un produit programme d'ordinateur sont proposés. 25 En particulier, un dispositif couplé à un analyseur lexical comprend des composants adaptés pour : 8 - identifier dans un code source reçu par l'analyseur lexical, une entité lexicale présentant une ambigüité d'interprétation relativement à une grammaire de langage donné ; - identifier dans une table des symboles associée à 5 l'analyseur lexical, l'existence d'un symbole pour ladite entité lexicale ; - déterminer pour le symbole identifié, la définition enregistrée dans la table des symboles; et - générer un jeton représentatif de ladite définition. Avantageusement, les composants pour identifier une entité 10 lexicale présentant une ambigüité d'interprétation comprennent des moyens pour déterminer si l'entité lexicale est un nom correspondant à un lexème de type « typedef-name ». Dans un mode de réalisation, le dispositif comprend des moyens pour définir dans la grammaire une première zone où les lexèmes 15 « typedef-name » sont différenciés de lexèmes « identifier », et une deuxième zone où lesdits lexèmes ne sont pas différenciés. Avantageusement, le dispositif comprend des moyens pour générer un jeton 'identifier' si le nom est dans la deuxième zone de la grammaire. 20 Dans un mode de réalisation, le dispositif comprend des moyens pour activer une recherche dans la table des symboles si le nom est dans la première zone de la grammaire. Dans une variante, les composants pour déterminer la définition de symbole enregistrée comprennent de plus des moyens pour déterminer si 25 le symbole est défini comme « typedef-name ». Selon cette variante, les composants pour générer un jeton comprennent des moyens pour générer un jeton `typedef-name'. Dans une autre variante, les 9 composants pour générer un jeton comprennent des moyens pour générer un jeton 'identifier' si le symbole n'est pas défini comme « typedef-name ». Avantageusement, le code source est en langage C et la 5 grammaire est la grammaire normée du langage C. Dans une implémentation préférentielle, le dispositif est implémenté dans un compilateur de code. L'invention concerne de plus un procédé pour gérer les ambigüités d'interprétation relativement à une grammaire de langage donné, le 10 procédé comprenant les étapes suivantes : - identifier dans un code source reçu par un analyseur lexical, une entité lexicale présentant une ambigüité d'interprétation; - identifier dans une table des symboles associée à l'analyseur lexical, l'existence d'un symbole pour ladite entité lexicale ; 15 - déterminer pour le symbole identifié, la définition enregistrée dans la table des symboles; et - générer un jeton représentatif de ladite définition. L'invention peut opérer sous la forme d'un produit programme d'ordinateur qui comprend des instructions de code permettant d'effectuer 20 les étapes du procédé revendiqué lorsque le programme est exécuté sur un ordinateur. Description des figures 3 0 1 83 6 8 10 Différents aspects et avantages de l'invention vont apparaître en appui de la description d'un mode préféré d'implémentation de l'invention mais non limitatif, avec référence aux figures ci-dessous : La figure 1 montre schématiquement les composants du dispositif de 5 l'invention dans une implémentation préférentielle; Les figures 2a et 2b montrent un enchaînement des étapes de la méthode de l'invention dans un mode de réalisation ; 10 Description détaillée de l'invention Référence est faite à la figure 1 qui montre de manière schématique un dispositif 100 comportant les composants d'une chaine d'analyse lexicale, syntaxique et sémantique pour une implémentation 15 préférentielle de l'invention dans un compilateur C. Un module d'analyse lexicale 120 reçoit du code source 102 en langage C. Le code source C peut provenir d'un fichier stocké sur l'ordinateur implémentant le dispositif 100 ou d'un ordinateur distant ou de tout autre support lisible par un ordinateur. Le module d'analyse lexicale 20 120 comprend un ensemble de composants d'analyse 122, communs à tout analyseur lexical, pour recevoir le code source et le décomposer en entités lexicales. L'analyseur lexical selon l'invention comprend de plus un composant de changement d'état 124 pour basculer un indicateur d'état 25 d'un état 'vrai' à un état 'faux' et vice versa. Dans une implémentation préférentielle, le composant est implémenté sous la forme d'une «"Application Programming Interface » - (API) selon l'anglicisme connu - 11 3018368 comprenant les fonctions permettant le changement de l'état de l'indicateur d'état. L'analyseur lexical 120 comprend en outre un composant de test 126 pour tester la valeur de l'indicateur d'état. Le test permet de vérifier la valeur de l'indicateur d'état pour déterminer la nature du jeton à émettre, soit un jeton « identifier », soit un jeton « typedef-name ». Le module d'analyse lexicale produit des jetons 104 vers un module d'analyse syntaxique 140. Le module d'analyse syntaxique 140 analyse les jetons reçus de l'analyseur lexical, génère un arbre syntaxique basé sur la grammaire utilisée, et génère des actions sémantiques (AST) 106 qui sont traitées par un module d'analyse sémantique 160. Dans une implémentation préférentielle, le module d'analyse syntaxique permet d'exploiter la grammaire de la norme ISO/ANSI C sans extension, dans laquelle la production listée au chapitre « 6.7.8 ISO/IEC 9899:2011 » est retirée. La grammaire du langage C est analysée de manière à déterminer une première zone où il est nécessaire de faire la distinction entre les entités « typedef-name » et « identifier », et une deuxième zone où il n'est pas nécessaire de faire cette distinction. Pour faciliter la compréhension de l'invention, dans la suite de la description, la zone de distinction est dénommée « zone active » et la zone sans distinction est dénommée « zone passive ». Par ailleurs, la grammaire est considérée représenter un espace où l'analyse syntaxique consiste à se déplacer dans cet espace en accord avec une méthode d'analyse syntaxique choisie. Chaque production de la grammaire (et le non-terminal en partie gauche de la production) représente un point de cet espace et les chemins permettant de l'atteindre. Chaque point de cet espace peut se voir attribuer une ou plusieurs actions sémantiques, qui sont effectuées lorsque l'analyseur syntaxique a terminé son analyse en ce point. 12 301 83 6 8 Lorsqu'un point se situe à la frontière entre les deux zones active et passive, une action sémantique est associée à ce point pour activer le composant d'indicateur d'état de l'analyseur lexical, suivant deux cas : - si le déplacement dans l'espace consiste en un passage de la 5 zone active à la zone passive, le composant de changement d'état 124 est activé pour basculer l'indicateur d'état de l'état vrai à l'état faux ; - si le déplacement dans l'espace consiste en un passage de la zone passive à la zone active, l'indicateur d'état est basculé de 10 l'état faux à l'état vrai. Le module d'analyse sémantique 160 reçoit les actions sémantiques issues de l'analyseur syntaxique pour les traiter et compléter l'arbre syntaxique. Il comprend un composant 162 pour la définition de 15 zonage de la grammaire qui définit la frontière entre la zone active et la zone passive. Le module d'analyse sémantique est de plus couplé à une mémoire 180. Dans une implémentation préférentielle, la mémoire est organisée comme une table des symboles qui permet d'enregistrer les 20 définitions des symboles. La mémoire est aussi couplée au module d'analyse lexicale. Les éléments (108) générés par le module d'analyse sémantique sont adressés à des composants du compilateur (non montrés sur la figure) pour finaliser les opérations de génération et d'optimisation de 25 code. Les figures 2a et 2b illustrent les étapes 200 opérées par la chaine de composants de la figure 1 dans une implémentation préférentielle de l'invention. 13 En figure 2a, le procédé débute à la lecture d'une suite de caractères d'un code source 202 soumis à l'analyseur lexical. L'étape suivante 204 consiste à extraire du code source des entités lexicales. Dans un mode de réalisation, la présente invention est implémentée dans un compilateur TC, dans sa portion analyse de C, avec le langage Smalltalk® dans lequel les concepts de structures sont les classes, les objets (les instances de classes), les méthodes (les comportements des objets) et les attributs (les variables d'état des objets). L'analyseur lexical est une classe « lexer » appelée CCScanner en charge de l'analyse lexicale. Le dispositif comprend une classe « parser » appelée CCParser correspondant à l'analyseur syntaxique en charge de l'analyse syntaxique et d'une partie de l'analyse sémantique. Le dispositif comprend de plus une classe de gestion de la table des symboles, appelée CScope. Dans cette implémentation préférentielle, le générateur de compilateur utilisé est Smalltalk Compiler-Compiler (SmaCC) qui définit les classes abstraites contenant la base comportementale de l'analyseur lexical et de l'analyseur syntaxique, ainsi que le compilateur d'analyseurs à partir de la grammaire et de la description lexicale. Lorsque les entités lexicales sont extraites, le procédé permet à l'étape 206 de tester si une entité est un nom correspondant à un lexème de type « typedef-name » ou non. Si l'entité n'est pas de type « typedefname » (branche Non), l'analyseur lexical produit un jeton approprié au type de l'entité (207). Si l'entité lexicale est un nom (branche Oui), le procédé envoie une requête (208) vers la table des symboles pour rechercher le symbole associé à l'entité. Le symbole est renvoyé à l'analyseur lexical. Le procédé permet de vérifier (étape 210) dans quelle zone de la grammaire l'entité est rencontrée pour déterminer si l'entité est dans la zone de grammaire active ou passive. Si l'entité rencontrée est dans la 30 zone de grammaire passive (branche Non), c'est-à-dire que le symbole a 14 déjà été rencontré et qu'il n'existe pas d'ambigüité dans son interprétation, l'analyseur lexical va produire un jeton de type 'identifier' (étape 216). Si l'entité rencontrée est dans la zone de grammaire active 5 (branche Oui, étape 210), signifiant qu'il existe une ambigüité dans son interprétation, le procédé poursuit à l'étape suivante (212) pour vérifier si le symbole est défini pour cette entité dans la table des symboles, et comment il est défini (type ou variable). Si le symbole est défini et qu'il est spécifié par son type comme « typedef-name » (branche Oui), le procédé 10 poursuit à l'étape 214 où l'analyseur lexical produit un jeton `typedefname'. Si le symbole n'a pas été précédemment défini, ou si le symbole est défini mais pas spécifié comme « typedef-name » (branche Non), le procédé poursuit à l'étape 216 où l'analyseur lexical produit un jeton `identifier' (étape 216). 15 Dans une réalisation implémentée dans un compilateur TC, la classe CCScanner définit un attribut « fTypename » initialisé à la valeur `vrai' (`true' en anglais) à la création d'une instance du scanner par la méthode (CCScanner»initialize). L'API de contrôle du dispositif est constituée de deux méthodes, (CCScanner»setFTypename) et 20 (CCScanner»unsetFTypename), la première mettant l'attribut à `true', la deuxième mettant l'attribut à 'false'. Si un message `setFTypename' est envoyé à une instance de CCScanner, l'attribut est mis à `true', et si un message `unsetFTypename' est envoyé à une instance de CCScanner, l'attribut est mis 'false'. Il est à noter que plusieurs instances peuvent 25 cohabiter de manière indépendante dans le programme, avec des états décorrélés. L'analyseur lexical CCScanner possède une routine `CCScanner»IDENTIFIER' qui est lancée quand un lexème du type « identifier » est détecté en entrée. La contextualisation est implémentée 15 en effectuant une requête sur la table des symboles (une instance de CScope). L'implémentation est réalisée par un test sur l'attribut fTypename suivant l'expression logique suivante : (fTypename and: [ symbol notNil and: [ symbol isTypename ] ]) signifiant que si fTypename est égal à `true', que le symbole existe (présence antérieure d'une déclaration dans le code source analysé) et qu'il est défini comme un 'type', alors par l'ensemble de ces conditions, l'analyseur lexical produit un jeton de type TypeNameld, sinon il produit un jeton de type IDENTIFIERId. Revenant à la figure 2b, après la production d'un jeton, soit `identifier' (216), soit `typedef-name' (214), le procédé poursuit à l'étape 218 par l'analyse syntaxique et l'exécution des actions sémantiques (106). Le procédé permet alors de vérifier (étape 220) si un point de l'analyse est situé à la frontière de la zone active et de la zone passive. Si le point n'est pas sur la frontière (branche Non), le procédé permet la génération de l'arbre de syntaxe (étape 228). Si le point est situé sur la frontière des deux zones (branche Oui), le procédé permet de déterminer le sens de déplacement dans l'espace (222) et vérifier de quelle zone de la grammaire l'entité provient. Si la zone de provenance est la zone active (branche Oui), signifiant que le sens de déplacement consiste en un passage de la zone active à la zone passive, le procédé permet d'actionner le dispositif de passage en zone (étape 224). Puis le procédé permet de générer l'arbre de syntaxe (228) prenant en compte les modifications. Si à la vérification de l'étape 222, la zone de provenance est la zone passive (branche Non), signifiant que le déplacement dans l'espace consiste en un passage de la zone passive à la zone active, le procédé permet d'actionner le dispositif de passage en zone active (étape 226). 16 Puis le procédé permet de générer des noeuds de l'arbre de syntaxe (228) prenant en compte les modifications, et les actions sémantiques correspondantes. Dans une implémentation préférentielle intégrée au compilateur TC, 5 la frontière entre les deux zones est implémentée dans l'analyseur sémantique et les zones sont matérialisées dans les actions sémantiques définies dans la grammaire, suivant la réalisation suivante : pour le passage de la zone active à la zone passive : l'action sémantique contient le code 'self unsetFTypename' qui active les 10 composants de l'analyseur lexical. pour le passage de la zone passive à la zone active : l'action sémantique contient le code 'self setFTypename' qui désactive les composants de l'analyseur lexical. 15 A tire d'exemple selon une implémentation pour la grammaire du langage C, pour une analyse qui commence en zone active, les frontières entre les deux zones sont identifiées aux points suivants : - pour le passage de la zone active à la zone passive : - Production : init_comma : « , » dans init_declaration_list 20 - Production : declaration_specifiers : declaration_specifier - Production : type_specifier : "void" {self unsetFTypename. ...I "char" {self unsetFTypename. ...I "short" {self unsetFTypename. ...I 25 "int" {self unsetFTypename. ...I "long" {self unsetFTypename. ...I "float" {self unsetFTypename. ...I "double" {self unsetFTypename. ...I "signed" {self unsetFTypename. ...I 30 "unsigned" {self unsetFTypename. ...I "_Bool" {self unsetFTypename. ...I "_Complex" {self unsetFTypename. ...I struct_or_union_specifier {self unsetFTypename. 17 I enum_specifier {self unsetFTypename. ...I {self unsetFTypename. ...I - Production : kr_declaration_specifiers: kr_declaration_specifier {self unsetFTypename. ...I - pour le passage de la zone passive à la zone active : - Production : declaration : declaration_specifiers ";" {self setFTypename. ...I - Production : direct_declarator : {self setFTypename. ...I - Production : parameter_declaration Ideclaration_specifiers abstract_declarator {self setFTypename....} I declaration_specifiers {self setFTypename. ...I - Production : type_name : specifier_qualifier_list {self setFTypename. ...I Ispecifier_qualifier_list abstract_declarator{self setFTypename....} - Production : param_paren : "C {self setFTypename. ...I - Production : left_block : {self setFTypename. Al '} Dans un mode de réalisation alternative, selon la technologie de l'analyseur syntaxique, un dispositif optionnel peut être ajouté à l'analyseur lexical pour faire une vérification sur un jeton d'avance (connu comme « look-ahead token » en anglais). Lors d'un changement d'état de l'indicateur d'état «typedefname » pour un tel jeton, qui a déjà été lu et généré par l'analyseur lexical mais pas encore traité complètement par l'analyseur syntaxique, s'il s'agit d'un jeton «identifier » et que le dispositif est mis à « vrai », le jeton est alors revérifié pour le passer en jeton « typedef-name » si l'action est appropriée. S'il s'agit d'un jeton « typedef- 18 name » et que le dispositif est mis à « faux », le jeton est passé en jeton « identifier ». Dans une implémentation préférentielle intégrée au compilateur TC, le dispositif optionnel est réalisé dans l'analyseur lexical sous la forme d'une API correspondante au dispositif (CCParser»setFTypename) et (CCParser»unsetFTypename) adaptée pour opérer le dispositif optionnel de la manière suivante : Le jeton en cours de traitement est contenu dans l'attribut « currentToken » de l'analyseur syntaxique. Si le dispositif (setFTypename) est activé, que le jeton est un « IDENTIFIERId » et son symbole existe et est un type, alors le jeton est changé en un « TypeNameld ». Si le dispositif (unsetFTypename) est désactivé, que le jeton est un 15 « TypeNameld » alors il est changé en un « IDENTIFIERId ». Dans les autres cas, le jeton en cours n'est pas modifié. Ainsi le procédé permet de gérer les ambigüités pouvant se présenter sur les déclarations de symboles. La présente invention peut s'implémenter à partir d'éléments 20 matériel et/ou logiciel. Elle peut être disponible en tant que produit programme d'ordinateur sur un support lisible par ordinateur. Le support peut être électronique, magnétique, optique, électromagnétique ou être un support de diffusion de type infrarouge. De tels supports sont par exemple, des mémoires à semi-conducteur (Random Access Memory 25 RAM, Read-Only Memory ROM), des bandes, des disquettes ou disques magnétiques ou optiques (Compact Disk - Read Only Memory (CD-ROM), Compact Disk - Read/Write (CD-R/W) and DVD). 19 REVENDICATIONS1. Un dispositif couplé à un analyseur lexical comprenant des composants adaptés pour : - identifier dans un code source reçu par l'analyseur lexical, une entité lexicale présentant une ambigüité d'interprétation relativement à une grammaire de langage donné ; - identifier dans une table des symboles associée à l'analyseur lexical, l'existence d'un symbole pour ladite entité lexicale ; - déterminer pour le symbole identifié, la définition enregistrée dans la table des symboles; et - générer un jeton représentatif de ladite définition. 2. Le dispositif selon la revendication 1, dans lequel les composants pour identifier une entité lexicale présentant une ambigüité d'interprétation comprennent des moyens pour déterminer si l'entité lexicale est un nom correspondant à un lexème de type « typedef-name ». 3. Le dispositif selon la revendication 2 comprenant de plus des moyens pour définir dans la grammaire une première zone où les lexèmes « typedef-name » sont différenciés de lexèmes « identifier », et une deuxième zone où lesdits lexèmes ne sont pas différenciés. 4. Le dispositif selon la revendication 3 comprenant de plus des moyens pour générer un jeton 'identifier' si le nom est dans la deuxième zone de la grammaire. 5. Le dispositif selon la revendication 3 comprenant de plus des moyens pour activer une recherche dans la table des symboles si le nom est dans la première zone de la grammaire. 6. Le dispositif selon la revendication 5 dans lequel les composants pour déterminer la définition de symbole enregistrée comprennent de plus des moyens pour déterminer si le symbole est défini comme « typedef-name ». 7. Le dispositif selon la revendication 6 dans lequel les composants pour générer un jeton comprennent des moyens pour générer un jeton `typedef-name'. 8. Le dispositif selon la revendication 6 dans lequel les composants pour générer un jeton comprennent des moyens pour générer un jeton `identifier' si le symbole n'est pas défini comme « typedef-name ». 9. Le dispositif selon l'une quelconque des revendications 1 à 8, dans lequel le code source est en langage C et la grammaire est la grammaire normée du langage C. 10. Un compilateur de code comprenant le dispositif selon l'une quelconque des revendications 1 à 9. 11. Un procédé pour gérer les ambigüités d'interprétation relativement à une grammaire de langage donné, comprenant les étapes suivantes : - identifier dans un code source reçu par un analyseur lexical, une entité lexicale présentant une ambigüité d'interprétation; - identifier dans une table des symboles associée à l'analyseur lexical, l'existence d'un symbole pour ladite entité lexicale ; 21 3018368 - déterminer pour le symbole identifié, la définition enregistrée dans la table des symboles; et - générer un jeton représentatif de ladite définition. 5 12. Le procédé selon la revendication 11 implémenté dans un dispositif selon l'une quelconque des revendications 1 à 10. 13. Un produit programme d'ordinateur, ledit programme d'ordinateur comprenant des instructions de code permettant d'effectuer tout ou 10 partie des étapes du procédé selon la revendication 11, lorsque ledit programme est exécuté sur un ordinateur. 15