yaccposix - En ligne dans le Cloud

PROGRAMME:

Nom

yacc — encore un autre compilateur de compilateur (PREMIUM)

SYNOPSIS

yacc [−dltv] [-b préfixe_fichier] [−p sym_préfixe] grammaire

DESCRIPTION

La yacc l'utilitaire doit lire une description d'une grammaire sans contexte dans grammaire et écris C
code source, conforme à la norme ISO C, dans un fichier de code et éventuellement un en-tête
informations dans un fichier d'en-tête, dans le répertoire courant. Le code source généré doit
ne dépend pas d'un comportement non défini, non spécifié ou défini par la mise en œuvre, sauf dans
cas où il est copié directement à partir de la grammaire fournie, ou dans les cas qui sont
documenté par la mise en œuvre. Le code C doit définir une fonction et les routines associées
et des macros pour un automate qui exécute un algorithme d'analyse répondant aux exigences de
Algorithmes.

La forme et la signification de la grammaire sont décrites dans la section DESCRIPTION ÉTENDUE.

Le code source C et le fichier d'en-tête doivent être produits sous une forme appropriée comme entrée pour le C
compilateur (voir c99).

OPTIONS

La yacc l'utilitaire doit être conforme au volume Base Definitions de POSIX.1‐2008, Section
12.2, utilitaire Syntaxe Recommandations, à l'exception de la ligne directrice 9.

Les options suivantes doivent être prises en charge :

-b préfixe_fichier
Utilisez préfixe_fichier au lieu de y comme préfixe pour tous les noms de fichiers de sortie. Le code
filet y.tab.c, le fichier d'en-tête y.tab.h (créé lorsque -d est spécifié), et le
fichier descriptif y.sortie (créé lorsque -v est spécifié), doit être remplacé par
préfixe_fichier.tab.c, préfixe_fichier.tab.het préfixe_fichier.sortir, Respectivement.

-d Écrivez le fichier d'en-tête ; par défaut, seul le fichier de code est écrit. Les #define
les instructions associent les codes de jeton attribués par yacc avec l'utilisateur déclaré
noms symboliques. Cela permet aux fichiers sources autres que y.tab.c pour accéder au jeton
codes.

−l Produire un fichier de code qui ne contient aucun #ligne construits. Si cette option
n'est pas présent, il n'est pas précisé si le fichier de code ou le fichier d'en-tête contient
#ligne directives. Cela ne doit être utilisé qu'après la grammaire et les
les actions sont entièrement déboguées.

−p sym_préfixe
Utilisez sym_préfixe au lieu de yy comme préfixe pour tous les noms externes produits par
yacc. Les noms affectés doivent inclure les fonctions yyparser() yylex(), et
yyerreur(), et les variables yylval, yycharet yydebug. (Dans le reste de
cette section, les six symboles cités sont référencés en utilisant leurs noms par défaut
uniquement à titre de commodité de notation.) Les noms locaux peuvent également être affectés par le −p
option; Cependant, le −p l'option n'affectera pas #define symboles générés par
yacc.

-t Modifier les directives de compilation conditionnelle pour permettre la compilation du débogage
code dans le fichier de code. Les instructions de débogage d'exécution doivent toujours être contenues dans
le fichier de code, mais par défaut les directives de compilation conditionnelles empêchent leur
compilation.

-v Ecrire un fichier contenant une description de l'analyseur et un rapport des conflits
générés par des ambiguïtés dans la grammaire.

OPÉRANDES

L'opérande suivant est obligatoire :

grammaire Un chemin d'accès d'un fichier contenant des instructions, ci-après appelé grammaire, Pour
lequel un analyseur doit être créé. Le format de la grammaire est décrit dans le
section DESCRIPTION ÉTENDUE.

STDIN

Non utilisé.

CONTRIBUTION DES DOSSIERS

Le fichier grammaire doit être un fichier texte formaté comme spécifié dans la DESCRIPTION ÉTENDUE
.

ENVIRONNEMENT VARIABLES

Les variables d'environnement suivantes doivent affecter l'exécution de yacc:

LANGUE Fournissez une valeur par défaut pour les variables d'internationalisation qui ne sont pas définies ou
nul. (Voir le volume Définitions de base de POSIX.1‐2008, Section 8.2,
Internationalisation Variables pour la priorité de l'internationalisation
variables utilisées pour déterminer les valeurs des catégories de paramètres régionaux.)

LC_TOUS S'il est défini sur une valeur de chaîne non vide, remplace les valeurs de tous les autres
variables d'internationalisation.

LC_CTYPE Déterminer la localisation pour l'interprétation des séquences d'octets de données de texte
sous forme de caractères (par exemple, des caractères à un octet par opposition aux caractères à plusieurs octets dans
arguments et fichiers d'entrée).

LC_MESSAGES
Déterminez les paramètres régionaux qui doivent être utilisés pour affecter le format et le contenu de
messages de diagnostic écrits dans l'erreur standard.

NLSPATH Déterminer l'emplacement des catalogues de messages pour le traitement des LC_MESSAGES.

La LANGUE ainsi que LC_ * les variables affectent l'exécution du yacc utilité comme indiqué. Les principal()
fonction définie dans Yacc Bibliothèque appellera :

setlocale(LC_ALL, "")

et donc le programme généré par yacc sera également affectée par le contenu de ces
variables à l'exécution.

ASYNCHRONE ÉVÉNEMENTS

Par défaut.

SORTIE STD

Non utilisé.

STDERR

Si des conflits de décalage/réduction ou de réduction/réduction sont détectés dans grammaire, yacc écrira un
rapport de ces conflits à l'erreur standard dans un format non spécifié.

L'erreur standard doit également être utilisée pour les messages de diagnostic.

SORTIE DES DOSSIERS

Le fichier de code, le fichier d'en-tête et le fichier de description doivent être des fichiers texte. Tous sont
décrites dans les sections suivantes.

Code Déposez votre dernière attestation
Ce fichier doit contenir le code source C pour le yyparser() fonction. Il doit contenir
code pour les différentes actions sémantiques avec substitution macro effectuée sur eux comme
décrit dans la section DESCRIPTION ÉTENDUE. Il doit également contenir une copie du #define
instructions dans le fichier d'en-tête. Si un %syndicat déclaration est utilisée, la déclaration de
YYSTYPE doit également être inclus dans ce fichier.

En-tête Déposez votre dernière attestation
Le fichier d'en-tête doit contenir #define déclarations qui associent les numéros de jeton avec le
noms symboliques. Cela permet aux fichiers sources autres que le fichier de code d'accéder aux codes de jeton.
Si un %syndicat déclaration est utilisée, la déclaration pour YYSTYPE et un externe YYTYPE yylval
déclaration doit également être incluse dans ce dossier.

Description Déposez votre dernière attestation
Le fichier de description doit être un fichier texte contenant une description de la machine d'état
correspondant à l'analyseur, utilisant un format quelconque. Limites pour les tables internes (voir
Limites) doivent également être signalés, d'une manière définie par la mise en œuvre. (Certaines implémentations
peut utiliser des techniques d'allocation dynamique et n'avoir aucune valeur limite spécifique à déclarer.)

ÉLARGI DESCRIPTION

La yacc la commande accepte une langue qui est utilisée pour définir une grammaire pour une langue cible
à analyser par les tables et le code généré par yacc. La langue acceptée par yacc en tant que
la grammaire de la langue cible est décrite ci-dessous à l'aide de la yacc langue d'entrée elle-même.

L'entrée grammaire comprend des règles décrivant la structure d'entrée de la langue cible et
code à invoquer lorsque ces règles sont reconnues pour fournir la sémantique associée
action. Le code à exécuter doit apparaître sous forme de corps de texte destinés à être C-
code de langue. Ces corps de texte ne doivent pas contenir de trigraphes en langage C. Le langage C
les inclusions sont présumées former une fonction correcte lorsqu'elles sont traitées par yacc dans sa sortie
des dossiers. Le code ainsi renseigné sera exécuté lors de la reconnaissance du
langue cible.

Étant donné une grammaire, le yacc L'utilitaire génère les fichiers décrits dans les FICHIERS DE SORTIE
section. Le fichier de code peut être compilé et lié en utilisant c99. Si la déclaration et
les sections programmes du fichier de grammaire ne comportaient pas de définitions de principal() yylex(), et
yyerreur(), la sortie compilée nécessite une liaison avec des versions fournies en externe de ces
les fonctions. Versions par défaut de principal() et yyerreur() sont fournis dans le yacc bibliothèque et
peut être lié en utilisant le −l y opérande à c99L’ yacc les interfaces de bibliothèque n'ont pas besoin
prend en charge les interfaces avec d'autres que la valeur par défaut yy préfixe de symbole. L'application fournit
la fonction d'analyse lexicale, yylex(); les lex utilitaire est spécialement conçu pour
générer une telle routine.

Entrée Langue
L'application doit s'assurer que chaque dossier de spécification se compose de trois sections dans
commande: déclarations, grammaire et programmes, séparés par un double
personnages ("%%"). Les sections déclarations et programmes peuvent être vides. Si ce dernier est
vide, le précédent "%%" la marque qui la sépare de la section des règles peut être omise.

L'entrée est un texte de forme libre suivant la structure de la grammaire définie ci-dessous.

Lexical Structure of le Grammaire
Les , , et caractère doit être ignoré, sauf que le
demande doit s'assurer qu'ils n'apparaissent pas dans les noms ou multi-caractères réservés
symboles. Les commentaires doivent être inclus dans "/* */", et peut apparaître partout où se trouve un nom
valide.

Les noms sont de longueur arbitraire, composés de lettres, de points ('.'), souligne ('_'), Et
chiffres non initiaux. Les majuscules et les minuscules sont distinctes. Candidatures conformes
n'utilisera pas de noms commençant par yy or YY depuis l' yacc l'analyseur utilise de tels noms. Un grand nombre de
les noms apparaissent dans la sortie finale de yacc, et donc ils devraient être choisis pour se conformer
avec toutes les règles supplémentaires créées par le compilateur C à utiliser. Ils apparaissent notamment
in #define Déclarations.

Un littéral doit consister en un seul caractère entouré de guillemets simples. Tous
les séquences d'échappement prises en charge pour les constantes de caractères par la norme ISO C doivent être
accompagnés par yacc.

La relation avec l'analyseur lexical est discutée en détail ci-dessous.

L'application doit s'assurer que le caractère NUL n'est pas utilisé dans les règles de grammaire ou
littéraux.

Déclarations Section
La section des déclarations permet de définir les symboles utilisés pour définir la langue cible
et leur relation les uns avec les autres. En particulier, la plupart des informations supplémentaires
nécessaire pour résoudre les ambiguïtés dans la grammaire sans contexte pour la langue cible est
fourni ici.

Habituellement yacc attribue la relation entre les noms symboliques qu'il génère et leur
valeur numérique sous-jacente. La section déclarations permet de contrôler les
l'attribution de ces valeurs.

Il est également possible de conserver des informations sémantiques associées aux jetons actuellement sur
la pile d'analyse dans un langage C défini par l'utilisateur union, si les membres du syndicat sont
associés aux différents noms de la grammaire. La section des déclarations prévoit
cela aussi.

Le premier groupe de déclarants ci-dessous prend tous une liste de noms comme arguments. Cette liste peut
éventuellement précédé du nom d'un membre du syndicat C (appelé Étiquette ci-dessous) apparaissant
dans les «<» ainsi que '>'. (Par exception aux conventions typographiques du reste de ce
volume de POSIX.1‐2008, dans ce casÉtiquette> ne représente pas une métavariable, mais le
caractères littéraux entre crochets entourant un symbole.) L'utilisation de Étiquette précise que le
les jetons nommés sur cette ligne doivent être du même type C que le membre de l'union référencé par
Étiquette. Ce point est discuté plus en détail ci-dessous.

Pour les listes utilisées pour définir des jetons, la première apparition d'un jeton donné peut être suivie de
un entier positif (sous forme de chaîne de chiffres décimaux). Si cela est fait, la valeur sous-jacente
qui lui est attribué à des fins lexicales est considéré comme étant ce numéro.

Ce qui suit déclare prénom être un jeton :

%jeton [<Étiquette>] prénom [nombre] [prénom [nombre]]

If Étiquette est présent, le type C pour tous les jetons sur cette ligne doit être déclaré comme étant le type
référencé par Étiquette. Si un entier positif, nombre, suit un prénom, cette valeur doit être
attribué au jeton.

Ce qui suit déclare prénom être un jeton, et lui attribue la priorité :

%la gauche [<Étiquette>] prénom [nombre] [prénom [nombre]]
%droit [<Étiquette>] prénom [nombre] [prénom [nombre]]

Une ou plusieurs lignes, chacune commençant par l'un de ces symboles, peuvent apparaître dans cette section.
Tous les jetons sur la même ligne ont le même niveau de priorité et la même associativité ; les lignes
sont par ordre croissant de priorité ou de force de liaison. %la gauche dénote que le
les opérateurs sur cette ligne sont laissés associatifs, et %droit désigne de la même manière la droite
opérateurs associatifs. Si Étiquette est présent, il doit déclarer un type C pour prénomcomme décrit
en %jeton.

Ce qui suit déclare prénom être un jeton, et indique qu'il ne peut pas être utilisé
associatif :

%nonassoc [<Étiquette>] prénom [nombre] [prénom [nombre]]

Si l'analyseur rencontre une utilisation associative de ce jeton, il signale une erreur. Si Étiquette is
présent, il doit déclarer un type C pour prénoms comme décrit pour %jeton.

Ce qui suit déclare que le membre du syndicat prénoms sont des non-terminaux, et il est donc nécessaire
avoir un Étiquette champ à son début :

%type <Étiquette> prénom

Parce qu'il ne traite que des non-terminaux, l'attribution d'un numéro de jeton ou l'utilisation d'un littéral est
également interdite. Si cette construction est présente, yacc doit effectuer une vérification de type ; si ce
construction n'est pas présente, la pile d'analyse ne doit contenir que le int type.

Chaque nom utilisé dans grammaire pas défini par un %jeton, %la gauche, %droitou %nonassoc
déclaration est supposée représenter un symbole non terminal. Les yacc le service public doit déclarer
une erreur pour tout symbole non terminal qui n'apparaît pas à gauche d'au moins un
règle de grammaire.

Une fois que le type, la priorité ou le numéro de jeton d'un nom est spécifié, il ne doit pas être
modifié. Si la première déclaration d'un token n'attribue pas de numéro de token, yacc doit
attribuer un numéro de jeton. Une fois cette affectation effectuée, le numéro de jeton ne doit pas être modifié
par affectation explicite.

Les déclarateurs suivants ne suivent pas le modèle précédent.

Ce qui suit déclare le non-terminal prénom à l' Commencer symbole, qui représente le
la structure la plus grande et la plus générale décrite par les règles de grammaire :

%début prénom

Par défaut, il s'agit du côté gauche de la première règle de grammaire ; cette valeur par défaut peut être
remplacé par cette déclaration.

Ce qui suit déclare le yacc pile de valeurs pour être une union des différents types de valeurs
voulu.

%syndicat { corps of union (in C)}

Le corps de l'union ne doit pas contenir de jetons de prétraitement d'accolades déséquilibrées.

Par défaut, les valeurs renvoyées par les actions (voir ci-dessous) et l'analyseur lexical seront
De type intL’ yacc l'utilitaire garde une trace des types, et il insère
les noms des membres de l'union afin d'effectuer une vérification de type stricte de l'analyseur résultant.

Alternativement, étant donné qu'au moins unÉtiquette> la construction est utilisée, l'union peut être déclarée
dans un fichier d'en-tête (qui sera inclus dans la section des déclarations à l'aide d'un #comprendre
construire à l'intérieur %{ ainsi que %}) et un typedef utilisé pour définir le symbole YYSTYPE pour représenter
ce syndicat. L'effet de %syndicat est de fournir la déclaration de YYSTYPE directement de
le yacc contribution.

Les déclarations et définitions en langage C peuvent apparaître dans la section des déclarations, jointe
par les marques suivantes :

%{ %}

Ces instructions doivent être copiées dans le fichier de code et avoir une portée globale à l'intérieur afin que
qu'ils peuvent être utilisés dans les sections de règles et de programme. Les déclarations ne doivent pas contenir
"%}" en dehors d'un commentaire, d'un littéral de chaîne ou d'une constante à plusieurs caractères.

L'application doit s'assurer que la section des déclarations est terminée par le jeton %%.

Grammaire Règles in yacc
La section des règles définit la grammaire sans contexte à accepter par la fonction yacc
génère et associe à ces règles des actions en langage C et une priorité supplémentaire
informations. La grammaire est décrite ci-dessous, et une définition formelle suit.

La section des règles est composée d'une ou plusieurs règles de grammaire. Une règle de grammaire a la forme :

A : CONTROLE DU ;

Le symbole A représente un nom non terminal, et CONTROLE DU représente une séquence de zéro ou
PLUS prénoms, littérals, et sémantique actions qui peut ensuite être suivi d'options
priorité exclures. Seuls les noms et les littéraux participent à la formation du
grammaire; les actions sémantiques et les règles de priorité sont utilisées d'autres manières. Les et
les sommes yacc ponctuation. S'il y a plusieurs règles de grammaire successives avec
le même côté gauche, le ('|') peut être utilisé pour éviter de réécrire le
côté gauche; dans ce cas le n'apparaît qu'après la dernière règle. Le corps
partie peut être vide (ou vide de noms et de littéraux) pour indiquer que le non-terminal
le symbole correspond à la chaîne vide.

La yacc L'utilitaire attribue un numéro unique à chaque règle. Règles utilisant la barre verticale
notation sont des règles distinctes. Le numéro attribué à la règle apparaît dans la description
fichier.

Les éléments composant un CORPS sont :

prénom, littéral
Celles-ci forment les règles de la grammaire : prénom est soit un jeton ou non terminal;
littéral se suffit à lui-même (moins les guillemets requis lexicalement).

sémantique action
A chaque règle de grammaire, l'utilisateur peut associer des actions à effectuer à chaque fois
la règle est reconnue dans le processus de saisie. (Notez que le mot « action » peut
font également référence aux actions de l'analyseur (décaler, réduire, etc.)

Ces actions peuvent retourner des valeurs et peuvent obtenir les valeurs retournées par les précédentes
Actions. Ces valeurs sont conservées dans des objets de type YYSTYPE (voir %syndicat). La
la valeur de résultat de l'action doit être conservée sur la pile d'analyse avec la main gauche
côté de la règle, auxquels accéder par d'autres réductions dans le cadre de leur main droite
côté. En utilisant leÉtiquette> les informations fournies dans la rubrique déclarations, le
code généré par yacc peut être strictement type vérifié et contenir arbitraire
informations. De plus, l'analyseur lexical peut fournir les mêmes types de
valeurs pour les jetons, si vous le souhaitez.

Une action est une instruction C arbitraire et, en tant que telle, peut effectuer une entrée ou une sortie, appeler
sous-programmes et modifier les variables externes. Une action est une ou plusieurs instructions C
enfermé dans des accolades '{' ainsi que '}'. Les déclarations ne doivent pas contenir
jetons de prétraitement des accolades déséquilibrées.

Certaines pseudo-variables peuvent être utilisées dans l'action. Ce sont des macros pour l'accès
aux structures de données connues en interne yacc.

$$ La valeur de l'action peut être définie en l'affectant à $$. Si tapez
la vérification est activée et le type de la valeur à affecter ne peut pas être
déterminé, un message de diagnostic peut être généré.

$nombre Il s'agit de la valeur renvoyée par le composant spécifié par le
jeton nombre dans la partie droite d'une règle, lecture de gauche à droite ;
nombre peut être nul ou négatif. Si nombre est nul ou négatif, il
fait référence aux données associées au nom sur la pile de l'analyseur
précédant le symbole le plus à gauche de la règle actuelle. (C'est-à-dire, «$ 0»
fait référence au nom précédant immédiatement le nom le plus à gauche dans le
la règle actuelle se trouve sur la pile de l'analyseur et "$−1" se réfère à la
symbole à ces gauche.) Si nombre fait référence à un élément au-delà du courant
point dans la règle, ou au-delà du bas de la pile, le résultat est
indéfini. Si la vérification de type est activée et le type de la valeur à
attribué ne peut pas être déterminé, un message de diagnostic peut être généré.

$<Étiquette>nombre
Ceux-ci correspondent exactement aux symboles correspondants sans le Étiquette
inclusion, mais autoriser une vérification de type stricte (et empêcher
conversions de type). L'effet est que la macro est étendue pour utiliser Étiquette
pour sélectionner un élément de l'union YYSTYPE (à l'aide nomdedonnées.tag).
Ceci est particulièrement utile si nombre n'est pas positif.

$<Étiquette>$ Ceci impose à la référence le type du membre du syndicat référencé
by Étiquette. Cette construction est applicable lorsqu'une référence à une gauche
la valeur de contexte apparaît dans la grammaire et fournit yacc avec un moyen
pour sélectionner un type.

Les actions peuvent se produire n'importe où dans une règle (pas seulement à la fin) ; une action peut accéder
valeurs renvoyées par les actions à sa gauche, et à son tour la valeur qu'il renvoie peut être
accessible par des actions à sa droite. Une action apparaissant au milieu d'une règle
équivaut à remplacer l'action par un nouveau symbole non terminal et
en ajoutant une règle vide avec ce symbole non terminal sur le côté gauche. Les
l'action sémantique associée à la nouvelle règle doit être équivalente à l'originale
action. L'utilisation d'actions dans les règles peut introduire des conflits qui ne
sinon exister.

Par défaut, la valeur d'une règle doit être la valeur du premier élément qu'elle contient.
Si le premier élément n'a pas de type (notamment dans le cas d'un
littéral) et la vérification de type est activée par %type, un message d'erreur doit apparaître.

priorité
Le mot-clé %préc peut être utilisé pour changer le niveau de priorité associé à un
règle de grammaire particulière. Des exemples de ceci sont dans les cas où un unaire et un binaire
opérateur ont la même représentation symbolique, mais doivent être donnés différents
précédences, ou lorsque le traitement d'une construction if-else ambiguë est
nécessaire. Le symbole réservé %préc peut apparaître immédiatement après le corps de
la règle de grammaire et peut être suivi d'un nom symbolique ou d'un littéral. Cela devrait
faire en sorte que la priorité de la règle de grammaire devienne celle du jeton suivant
nom ou littéral. L'action pour la règle dans son ensemble peut suivre %préc.

Si une section de programme suit, l'application doit s'assurer que les règles de grammaire sont
terminé par %%.

Programmes Section
La programmes la section peut inclure la définition de l'analyseur lexical yylex(), et n'importe quel
autres fonctions; par exemple, ceux utilisés dans les actions spécifiées dans les règles de grammaire. Ce
n'est pas spécifié si la section programmes précède ou suit les actions sémantiques dans
le fichier de sortie ; par conséquent, si l'application contient des définitions de macro et
déclarations destinées à s'appliquer au code dans les actions sémantiques, il les place
dans les " %{ %}" dans la rubrique déclarations.

Entrée Grammaire
L'entrée suivante à yacc produit un analyseur pour l'entrée à yacc. Cette syntaxe formelle
a priorité sur la description de la syntaxe du texte précédent.

La structure lexicale est définie de manière moins précise ; Lexical Structure of le Grammaire définit
la plupart des termes. La correspondance entre les termes précédents et les jetons ci-dessous est comme
suit.

IDENTIFICATEUR Cela correspond à la notion de prénom, donné précédemment. Il comprend également
littéraux tels que définis précédemment.

C_IDENTIFIANT
C'est un nom, et en plus il est connu pour être suivi d'un . UNE
Le littéral ne peut pas produire ce jeton.

NUMÉRO Une chaîne de chiffres (un entier décimal non négatif).

TYPE, en stock, MARK, URLLC, URLRC
Ceux-ci correspondent directement à %type, %la gauche, %%, %{et %}.

{ } Cela indique le code source en langage C, avec l'inclusion possible de «$»
macros comme discuté précédemment.

/* Grammaire en le contribution à ouais. */
/* Basic entrées. */
/* La Abonnement reconnu by le lexical analyseur. */

%token IDENTIFIER /* Inclut les identifiants et les littéraux */
%token C_IDENTIFIER /* identifiant (mais pas littéral)
suivi d'un :. */
%jeton NUMÉRO /* [0-9][0-9]* */

/* Mots réservés : %type=>TYPE %left=>LEFT, et ainsi de suite */

%token GAUCHE DROITE NONASSOC TOKEN PREC TYPE START UNION

%token MARK /* La marque %%. */
%token LCURL /* La marque %{. */
%token RCURL /* La marque %}. */

/* Les littéraux de caractères 8 bits se suffisent à eux-mêmes ; */
/* les jetons doivent être définis pour les caractères multi-octets. */

%start spécification

%%

spec : defs MARK règles queue
;
queue : MARQUE
{
/* Dans cette action, configurez le reste du fichier. */
}
| /* Vide; le deuxième MARK est facultatif. */
;
defs : /* Vide. */
| def def
;
def : IDENTIFIANT DE DEBUT
| SYNDICAT
{
/* Copie la définition de l'union dans la sortie. */
}
| URLLC
{
/* Copie le code C dans le fichier de sortie. */
}
URLRC
| nlist de balises rword
;
mot-clé : JETON
| LA GAUCHE
| DROIT
| NON-ASSOC
| TAPER
;
tag : /* Vide : ID de tag d'union facultatif. */
| '<' IDENTIFIANT '>'
;
nliste : nmno
| nlist nmno
;
nmno : IDENTIFIER /* Remarque : littéral invalide avec le type %. */
| IDENTIFIANT NUMBER /* Remarque : invalide avec le type %. */
;

/* Section de règles */

règles : C_IDENTIFIER rbody prec
| règles règle
;
règle : C_IDENTIFIER rbody prec
| '|' corps prec
;
corps : /* vide */
| IDENTIFIANT corps
| acte de corps
;
agir : '{'
{
/* Copier l'action, traduire $$, et ainsi de suite. */
}
'}'
;
prec : /* Vide */
| IDENTIFIANT PREC
| acte PREC IDENTIFIANT
| prec ';'
;

Conflits
L'analyseur syntaxique produit pour une grammaire d'entrée peut contenir des états dans lesquels des conflits surviennent. Les
les conflits se produisent parce que la grammaire n'est pas LALR(1). Une grammaire ambiguë contient toujours
au moins un LALR(1) conflit. Les yacc l'utilitaire doit résoudre tous les conflits, en utilisant soit
les règles par défaut ou les règles de priorité spécifiées par l'utilisateur.

Les conflits sont soit des conflits de décalage/réduction, soit des conflits de réduction/réduction. Un décalage/réduction
le conflit est l'endroit où, pour un état et un symbole d'anticipation donnés, à la fois une action de décalage et un
réduire l'action sont possibles. Un conflit réduire/réduire est l'endroit où, pour un état donné et
symbole d'anticipation, des réductions par deux règles différentes sont possibles.

Les règles ci-dessous décrivent comment spécifier les actions à entreprendre lorsqu'un conflit survient. Pas
tous les conflits de décalage/réduction peuvent être résolus avec succès de cette façon car le conflit peut
être due à autre chose qu'à l'ambiguïté, de sorte que l'utilisation imprudente de ces installations peut causer
le langage accepté par l'analyseur syntaxique est très différent de celui qui était prévu. Les
le fichier de description doit contenir suffisamment d'informations pour comprendre la cause de la
conflit. Lorsque l'ambiguïté est la raison pour laquelle les règles par défaut ou explicites doivent être
suffisant pour produire un analyseur fonctionnel.

Les préséances et associativités déclarées (voir Déclarations Section) être habitué
résoudre les conflits d'analyse comme suit :

1. Une précédence et une associativité sont associées à chaque règle de grammaire ; c'est le
priorité et associativité du dernier jeton ou littéral dans le corps de la règle. Si
le %préc mot-clé est utilisé, il remplace cette valeur par défaut. Certaines règles de grammaire peuvent ne pas
ont à la fois préséance et associativité.

2. S'il y a un conflit décalage/réduction, et à la fois la règle de grammaire et le symbole d'entrée
ont la priorité et l'associativité qui leur sont associées, alors le conflit est résolu
en faveur de l'action (décaler ou réduire) associée à la priorité la plus élevée. Si la
les précédences sont les mêmes, alors l'associativité est utilisée ; associatif gauche implique
réduire, associatif à droite implique décalage, et non associatif implique une erreur dans le
chaîne en cours d'analyse.

3. Lorsqu'il y a un conflit décalage/réduction qui ne peut pas être résolu par la règle 2, le décalage est
terminé. Les conflits résolus de cette manière sont comptabilisés dans la sortie de diagnostic décrite dans
Erreur Maniabilité.

4. Lorsqu'il y a un conflit réduction/réduction, une réduction est effectuée par la règle de grammaire qui
se produit plus tôt dans la séquence d'entrée. Les conflits ainsi résolus sont comptabilisés dans le
sortie de diagnostic décrite dans Erreur Maniabilité.

Les conflits résolus par priorité ou associativité ne doivent pas être comptés dans le décalage/réduction
et réduire/réduire les conflits signalés par yacc sur l'erreur standard ou dans le
fichier descriptif.

Erreur Maniabilité
Le jeton erreur sont réservés au traitement des erreurs. Le nom erreur peut être utilisé dans
règles de grammaire. Il indique les endroits où l'analyseur peut récupérer d'une erreur de syntaxe. Les
valeur par défaut de erreur doit être 256. Sa valeur peut être modifiée à l'aide d'un %jeton déclaration.
L'analyseur lexical ne doit pas renvoyer la valeur de erreur.

L'analyseur doit détecter une erreur de syntaxe lorsqu'il est dans un état où l'action associée
avec le symbole d'anticipation est erreur. Une action sémantique peut provoquer le lancement de l'analyseur
gestion des erreurs en exécutant la macro YYERROR. Lorsque YYERROR est exécuté, la sémantique
l'action redonne le contrôle à l'analyseur. YYERROR ne peut pas être utilisé en dehors de la sémantique
actions.

Lorsque l'analyseur détecte une erreur de syntaxe, il appelle normalement yyerreur() avec le caractère
un magnifique "syntaxe Erreur" comme argument. L'appel ne doit pas être effectué si l'analyseur est toujours
récupérer d'une erreur précédente lorsque l'erreur est détectée. L'analyseur est considéré comme
récupérer d'une erreur précédente jusqu'à ce que l'analyseur se soit déplacé sur au moins trois
symboles d'entrée normaux depuis que la dernière erreur a été détectée ou qu'une action sémantique a été exécutée
la macro yyerrok. L'analyseur ne doit pas appeler yyerreur() lorsque YYERROR est exécuté.

La fonction macro YYRECOVERING doit retourner 1 si une erreur de syntaxe a été détectée et le
l'analyseur ne s'en est pas encore complètement remis. Dans le cas contraire, zéro doit être renvoyé.

Lorsqu'une erreur de syntaxe est détectée par l'analyseur, l'analyseur doit vérifier si une syntaxe précédente
une erreur a été détectée. Si une erreur précédente a été détectée et si aucun symbole d'entrée normal
ont été décalés depuis que l'erreur précédente a été détectée, l'analyseur vérifie si le
le symbole d'anticipation est un marqueur final (voir Interfaces à le Lexical Analyzer). Si c'est le cas, le
l'analyseur doit retourner avec une valeur non nulle. Sinon, le symbole d'anticipation doit être
supprimé et l'analyse normale doit reprendre.

Lorsque YYERROR est exécuté ou lorsque l'analyseur détecte une erreur de syntaxe et aucune erreur précédente
a été détecté, ou au moins un symbole d'entrée normal a été déplacé depuis le précédent
erreur a été détectée, l'analyseur doit revenir en arrière un état à la fois jusqu'à ce que la pile d'analyse soit
vide ou l'état actuel permet un décalage erreur. Si l'analyseur vide l'analyse
pile, il doit retourner avec une valeur non nulle. Sinon, il se déplacera sur erreur ainsi que
puis reprenez l'analyse normale. Si l'analyseur lit un symbole d'anticipation avant que l'erreur ne soit
détecté, ce symbole doit toujours être le symbole d'anticipation lors de la reprise de l'analyse.

La macro yyerrok dans une action sémantique doit amener l'analyseur à agir comme s'il avait pleinement
récupéré de toutes les erreurs précédentes. La macro yyclearin doit faire en sorte que l'analyseur élimine
le jeton d'anticipation actuel. Si le jeton d'anticipation actuel n'a pas encore été lu,
yyclearin n'aura aucun effet.

La macro YYACCEPT provoquera le retour de l'analyseur avec la valeur zéro. La macro YYABORT
doit faire en sorte que l'analyseur renvoie une valeur non nulle.

Interfaces à le Lexical Analyzer
La yylex() est une fonction à valeur entière qui renvoie un jeton nombre
représentant le type de jeton lu. S'il y a une valeur associée au jeton
retourné par yylex() (voir la discussion de Étiquette ci-dessus), il est attribué au
variable externe yylval.

Si l'analyseur et yylex() ne sont pas d'accord sur ces numéros de jeton, communication fiable
entre eux ne peut pas se produire. Pour les littéraux (caractères à un octet), le jeton est simplement le
valeur numérique du caractère dans le jeu de caractères actuel. Les numéros des autres jetons
peut être choisi par yacc, ou choisi par l'utilisateur. Dans les deux cas, le #define construire
de C est utilisé pour permettre yylex() pour renvoyer ces nombres symboliquement. Les #define déclarations
sont mis dans le fichier de code, et le fichier d'en-tête si ce fichier est demandé. L'ensemble des
caractères autorisés par yacc dans un identifiant est plus grand que celui autorisé par C. Token
les noms contenant de tels caractères ne doivent pas être inclus dans le #define déclarations.

Si les numéros de jeton sont choisis par yacc, les jetons autres que les littéraux sont attribués
nombres supérieurs à 256, bien qu'aucun ordre ne soit implicite. Un jeton peut être attribué explicitement
un nombre en faisant suivre sa première apparition dans la section des déclarations d'un nombre.
Les noms et les littéraux non définis de cette manière conservent leur définition par défaut. Tous les numéros de jeton
assigné par yacc doivent être uniques et distincts des numéros symboliques utilisés pour les littéraux et
jetons attribués par l'utilisateur. Si des numéros de jetons en double provoquent des conflits dans la génération de l'analyseur,
yacc doit signaler une erreur ; sinon, il n'est pas spécifié si l'attribution du jeton est
accepté ou une erreur est signalée.

La fin de la saisie est marquée par un jeton spécial appelé le marqueur, qui a un jeton
nombre qui est nul ou négatif. (Ces valeurs ne sont pas valides pour tout autre jeton.) Tous
les analyseurs lexicaux doivent renvoyer zéro ou négatif comme nombre symbolique lorsqu'ils atteignent la fin de
leur entrée. Si les jetons jusqu'à, mais à l'exclusion, le marqueur final forment une structure qui
correspond au symbole de début, l'analyseur doit accepter l'entrée. Si le marqueur final est vu dans
dans tout autre contexte, il sera considéré comme une erreur.

Fin le Programme
En plus des yyparser() et yylex(), les fonctions yyerreur() et principal() sont tenus de
faire un programme complet. L'application peut fournir principal() et yyerreur(), ou celles-ci
les routines peuvent être obtenues à partir du yacc bibliothèque.

Yacc Bibliothèque
Les fonctions suivantes ne doivent apparaître que dans le yacc bibliothèque accessible via le −l y
opérande à c99; ils peuvent donc être redéfinis par une application conforme :

int principal(annuler)
Cette fonction appelle yyparser() et quitter avec une valeur non spécifiée. D'autres actions
au sein de cette fonction ne sont pas spécifiés.

int yyerreur(const carboniser *s)
Cette fonction écrira l'argument terminé par NUL dans l'erreur standard, suivi de
une .

L'ordre du −l y ainsi que −l l opérandes donnés à c99 est important ; la demande doit
soit fournir le sien principal() fonctionner ou s'assurer que −l y Il précède −l l.

Débogage le Analyseur
L'analyseur généré par yacc doit avoir des installations de diagnostic qui peuvent être facultativement
activé au moment de la compilation ou à l'exécution (si activé au moment de la compilation). Les
la compilation du code de débogage d'exécution est sous le contrôle de YYDEBUG, un préprocesseur
symbole. Si YYDEBUG a une valeur non nulle, le code de débogage doit être inclus. Si c'est
valeur est zéro, le code ne doit pas être inclus.

Dans les parseurs où le code de débogage a été inclus, le int yydebug peuvent être
utilisé pour activer (avec une valeur non nulle) et désactiver (valeur nulle) le débogage au moment de l'exécution. Les
valeur initiale de yydebug doit être nul.

Quand -t est spécifié, le fichier de code doit être construit de telle sorte que, si YYDEBUG n'est pas déjà
défini au moment de la compilation (à l'aide du c99 -D option YYDEBUG, par exemple), YYDEBUG doit
être défini explicitement sur 1. Lorsque -t n'est pas spécifié, le fichier de code doit être construit de telle sorte que,
si YYDEBUG n'est pas déjà défini, il doit être mis explicitement à zéro.

Le format de la sortie de débogage n'est pas spécifié mais comprend au moins suffisamment d'informations
pour déterminer les actions de décalage et de réduction, et les symboles d'entrée. Il fournit également
informations sur la récupération d'erreurs.

Algorithmes
L'analyseur syntaxique construit par yacc met en œuvre un LALR(1) algorithme d'analyse tel que documenté dans
la littérature. Il n'est pas spécifié si l'analyseur est piloté par table ou à codage direct.

Un analyseur généré par yacc ne doit jamais demander un symbole d'entrée à yylex() alors que dans un
état où les seules actions autres que l'action d'erreur sont des réductions par une seule règle.

La littérature de la théorie de l'analyse syntaxique définit ces concepts.

Limites
La yacc L'utilitaire peut avoir plusieurs tables internes. Les maximums minimaux pour ces tableaux
sont indiqués dans le tableau suivant. La signification exacte de ces valeurs est la mise en œuvre-
défini. La mise en œuvre doit définir la relation entre ces valeurs et entre
eux et tous les messages d'erreur que l'implémentation peut générer en cas de manque de
espace pour toute structure interne. Une implémentation peut combiner des groupes de ces ressources
dans un seul pool tant que le total disponible pour l'utilisateur ne tombe pas en dessous de la somme
des tailles spécifiées par cette section.

Tableau: Interne Limites in yacc

?? ??
│ Minimum │
│ limite │ Maximum │ Description │
?? ??
│{NTERMS} │ 126 │ Nombre de jetons. ??
│{NNONTERM} │ 200 │ Nombre de non-terminaux. ??
│{NPROD} │ 300 │ Nombre de règles. ??
│{NSTATES} │ 600 │ Nombre d'états. ??
│{MEMSIZE} │ 5200 │ Longueur des règles. Le total │
│ │ │ longueur, en noms (jetons et │
│ │ │ non-terminaux), de tous les │
│ │ règles de la grammaire. Le
│ │ │ le côté gauche est compté pour │
│ │ │ chaque règle, même si ce n'est pas le cas │
│ │ │ explicitement répété, comme │
│ │ │ spécifié dans Grammaire Règles in │
│ │ yacc. ??
│{ACTSIZE} │ 4000 │ Nombre d'actions. ``Actions'' │
│ │ ici (et dans la description
│ │ │ file) font référence aux actions de l'analyseur
│ │ │ (décaler, réduire, etc.) pas │
│ │ │ aux actions sémantiques définies dans │
│ │ Grammaire Règles in yacc. ??
?? ??

EXIT STATUT

Les valeurs de sortie suivantes doivent être renvoyées :

0 Achèvement réussi.

>0 Une erreur s'est produite.

CONSÉQUENCES OF LES ERREURS

Si des erreurs sont rencontrées, l'exécution est interrompue et yacc sort avec un statut différent de zéro.
Des fichiers de code partiels et des fichiers d'en-tête peuvent être produits. Les informations récapitulatives dans le
fichier de description doit toujours être produit si le -v le drapeau est présent.

La Abonnement les sections informatif.

INSCRIPTION UTILISATION

Les implémentations historiques connaissent des conflits de noms sur les noms yacc.tmp, yacc.acts,
yacc.debug, y.tab.c, y.tab.het y.sortie si plus d'un exemplaire de yacc fonctionne dans un
un seul répertoire à la fois. Les -b option a été ajoutée pour surmonter ce problème. Les
problème connexe d'autoriser plusieurs yacc parseurs à placer dans le même fichier a été
résolu en ajoutant un −p option pour remplacer le code précédemment codé en dur yy préfixe variable.

La description du −p option spécifie l'ensemble minimal de noms de fonction et de variable
qui provoquent des conflits lorsque plusieurs analyseurs sont liés entre eux. YYSTYPE n'a pas besoin d'être
modifié. Au lieu de cela, le programmeur peut utiliser -b pour donner les fichiers d'en-tête pour différents parseurs
des noms différents, puis le fichier avec le yylex() pour un analyseur syntaxique donné peut inclure le
en-tête pour cet analyseur. Des noms tels que yyclearerr n'ont pas besoin d'être modifiés car ils
ne sont utilisés que dans les actions ; ils n'ont pas de lien. Il est possible qu'un
l'implémentation a d'autres noms, soit internes pour implémenter des choses telles que
yyclearerr, ou fournir des fonctionnalités non standard avec lesquelles il souhaite modifier −p.

Les opérateurs unaires qui sont le même jeton qu'un opérateur binaire en général ont besoin de leur
priorité ajustée. Ceci est géré par le %préc symbole de mise en garde associé au
règle de grammaire particulière définissant cet opérateur unaire. (Voir Grammaire Règles in yacc.)
Les applications ne sont pas obligées d'utiliser cet opérateur pour les opérateurs unaires, mais les grammaires
qui n'en ont pas besoin sont rares.

EXEMPLES

L'accès à la yacc bibliothèque est obtenue avec des opérandes de recherche de bibliothèque pour c99. Pour utiliser le
yacc bibliothèque principal†

c99 y.tab.c −l y

Tant le lex bibliothèque et le yacc bibliothèque contient principal(). Pour accéder au yacc principal†

c99 y.tab.c lex.aa.c −l y −l l

Cela garantit que le yacc bibliothèque est recherchée en premier, de sorte que sa principal() est utilisé.

L'historique yacc les bibliothèques ont contenu deux fonctions simples qui sont normalement codées
par le programmeur de l'application. Ces fonctions sont similaires au code suivant :

#comprendre
int principal (vide)
{
externe int yyparse();

setlocale(LC_ALL, "");

/* Si l'analyseur suivant est un créé par lex, le
l'application doit veiller à ce que LC_CTYPE
et LC_COLLATE sont définis sur la locale POSIX. */
(vide) yyparse();
retour (0);
}

#inclut

int yyerror(const char *msg)
{
(void) fprintf(stderr, "%s\n", msg);
retour (0);
}

RAISONNEMENT

Les références en Référencé DOCUMENTS peut être utile dans la construction de l'analyseur syntaxique
Générateur. L'article référencé de DeRemer et Pennello (ainsi que les travaux qu'il
références) décrit une technique pour générer des analyseurs qui se conforment à ce volume de
POSIX.1‐2008. Le travail dans ce domaine continue d'être effectué, les responsables de la mise en œuvre devraient donc consulter
la littérature actuelle avant de faire de nouvelles implémentations. L'article original de Knuth est le
base théorique de ce type d'analyseur, mais les tableaux qu'il génère sont peu pratiques
grand pour les grammaires raisonnables et ne doit pas être utilisé. Le libellé « équivalent à » est
intentionnel de s'assurer que les meilleures tables qui sont LALR(1) peut être généré.

Il y a eu confusion entre la classe des grammaires, les algorithmes nécessaires pour générer
analyseurs, et les algorithmes nécessaires pour analyser les langues. Ils sont tous raisonnablement
orthogonal. En particulier, un générateur d'analyseur syntaxique qui accepte la gamme complète de LR(1)
les grammaires n'ont pas besoin de générer une table plus complexe que celle qui accepte SLR(1) (un
classe relativement faible de grammaires LR) pour une grammaire qui se trouve être SLR(1). Un tel
la mise en œuvre n'a pas non plus besoin de reconnaître le cas; la compression de table peut donner SLR(1)
table (ou une encore plus petite que cela) sans reconnaître que la grammaire est SLR(1). le
vitesse d'un LR(1) l'analyseur syntaxique pour n'importe quelle classe dépend davantage de la représentation de la table et
compression (ou la génération de code si un analyseur direct est généré) que sur la classe
de grammaire que le générateur de table gère.

La vitesse du générateur d'analyseur syntaxique dépend quelque peu de la classe de grammaire qu'il
poignées. Cependant, les algorithmes d'origine de l'article de Knuth pour la construction d'analyseurs LR ont été
jugé par son auteur comme peu pratique à l'époque. Bien que le LR complet soit plus
complexe que LALR(1), à mesure que la vitesse des ordinateurs et les algorithmes s'améliorent, la différence (en termes
du temps d'exécution acceptable de l'horloge murale) devient moins important.

Les auteurs potentiels sont avertis que l'article référencé de DeRemer et Pennello
précédemment cité identifie un bogue (une simplification excessive du calcul de LALR(1)
jeux d'anticipation) dans certains des LALR(1) déclarations d'algorithme qui l'ont précédé à
publication. Ils devraient prendre le temps de rechercher ce document, ainsi que les informations pertinentes
travail, en particulier celui d'Aho.

La -b option a été ajoutée pour fournir une méthode portable pour permettre yacc travailler sur
plusieurs analyseurs séparés dans le même répertoire. Si un répertoire contient plusieurs
yacc grammaire, et les deux grammaires sont construites en même temps (par, par exemple, un
parallèle faire programme), les résultats des conflits. Bien que la solution ne soit pas la pratique historique,
il corrige une lacune connue dans les implémentations historiques. Les changements correspondants ont été
fait à toutes les sections qui référençaient les noms de fichiers y.tab.c (maintenant ``le fichier de code''),
y.tab.h (maintenant ``le fichier d'en-tête''), et y.sortie (maintenant ``le fichier de description'').

La grammaire pour yacc l'entrée est basée sur la documentation System V. La description textuelle
y montre que le ';' est obligatoire à la fin de la règle. La grammaire et le
la mise en œuvre ne l'exige pas. (L'utilisation de C_IDENTIFIANT provoque une réduction dans
au bon endroit.)

De plus, dans cette mise en œuvre, les constructions telles que %jeton peut être résilié par un
, mais cela n'est pas autorisé par la grammaire. Les mots-clés tels que %jeton vous
apparaissent également en majuscules, ce qui n'est pas non plus discuté. Dans la plupart des endroits où '%' est utilisé,
peut être substitué, et il existe des orthographes alternatives pour certains des symboles
(par exemple, %LA GAUCHE peuvent être "%<" ou encore "\<").

Historiquement,Étiquette> peut contenir n'importe quel caractère sauf '>', y compris l'espace blanc, dans le
la mise en oeuvre. Cependant, depuis le Étiquette doit faire référence à un membre du syndicat de la norme ISO C, dans
les implémentations conformes à la pratique doivent prendre en charge uniquement l'ensemble de caractères pour ISO C
identifiants standards dans ce contexte.

Certaines implémentations historiques sont connues pour accepter des actions qui sont terminées par un
période. Les implémentations historiques permettent souvent «$» dans les noms. Une mise en œuvre conforme
n'a pas besoin de soutenir l'un ou l'autre de ces comportements.

Décider quand utiliser %préc illustre la difficulté de spécifier le comportement de yacc.
Il peut y avoir des situations dans lesquelles le grammaire n'est pas, à proprement parler, dans l'erreur, et pourtant
yacc ne peut pas l'interpréter sans ambiguïté. La résolution des ambiguïtés dans la grammaire peut
dans de nombreux cas être résolu en fournissant des informations supplémentaires, telles que l'utilisation %type or
%syndicat déclarations. C'est souvent plus facile et cela donne généralement un analyseur plus petit à prendre
cette alternative lorsqu'elle est appropriée.

La taille et le temps d'exécution d'un programme produit sans le code de débogage d'exécution est
généralement plus petit et légèrement plus rapide dans les implémentations historiques.

Les messages de statistiques de plusieurs implémentations historiques incluent les types de
informations:

n/512 bornes, n/300 non-terminaux
n/600 règles de grammaire, n/1500 états
n décaler/réduire, n réduire/réduire les conflits signalés
n/350 sets de travail utilisés
Mémoire : états, etc. n/15000, analyseur n/ 15000
n/600 ensembles d'anticipation distincts
n fermetures supplémentaires
n écritures de décalage, n exceptions
n aller aux entrées
n entrées enregistrées par goto default
Espace de l'optimiseur utilisé : entrée n/15000, sortie n/ 15000
n entrées de table, n zéro
Diffusion maximale : n, Décalage maximal : n

Le rapport des tables internes dans le fichier de description est laissé à l'implémentation
car tous les aspects de ces limites sont également définis par la mise en œuvre. Quelques implémentations
peuvent utiliser des techniques d'allocation dynamique et n'ont pas de valeurs limites spécifiques à déclarer.

Le format du y.sortie fichier n'est pas fourni car la spécification du format n'a pas été
vu pour améliorer la portabilité des applications. La liste est principalement destinée à aider les humains
les utilisateurs comprennent et déboguent l'analyseur ; utilisation de y.sortie par un script d'application conforme
serait inhabituel. De plus, les mises en œuvre n'ont pas produit de résultats cohérents et aucun
format populaire était évident. Le format choisi par la mise en œuvre doit être humain-
lisible, en plus de l'exigence qu'il s'agisse d'un fichier texte.

Les rapports d'erreurs standard ne sont pas spécifiquement décrits car ils sont rarement utiles pour
applications conformes et il n'y avait aucune raison de restreindre les implémentations.

Certaines implémentations reconnaissent "={" comme équivalent à '{' car il apparaît dans l'historique
Documentation. Cette construction a été reconnue et documentée comme obsolète dès
1978, dans la référence Yacc : Cela dit le dévouement, détermination et courage de Une autre Compilateur-Compilateur. Ce volume de POSIX.1‐2008
a choisi de le laisser comme obsolète et de l'omettre.

Les caractères multi-octets doivent être reconnus par l'analyseur lexical et renvoyés sous forme de jetons.
Ils ne doivent pas être renvoyés sous forme de littéraux de caractères multi-octets. Le jeton erreur qui est utilisé
pour la récupération d'erreur, la valeur 256 est normalement attribuée dans l'implémentation historique.
Ainsi, la valeur de jeton 256, qui est utilisée dans de nombreux jeux de caractères multi-octets, n'est pas
disponible pour être utilisé comme valeur d'un jeton défini par l'utilisateur.

FUTUR DIRECTIONS

Aucun.

Utilisez yaccposix en ligne en utilisant les services onworks.net