En plus de ne pas fermer un commentaire / * ... , ce qui constitue une erreur lexicale en C?
6 Réponses :
Voici quelques-unes:
#if x %
Hum ... String non-ferme. J'aurais dû penser à cela quand j'ai vu le même commentaire de fermeture. Mais merci, valide!
Voulez-vous envisager "abc
@DR Beco: Tain de moi ... La version standard de C Je pense désactive les littéraux de chaîne contenant de nouvelles lignes. IIRC, certaines versions de GCC (pas une norme) l'ont autorisé; Que ce soit encore, je ne sais pas.
@Ira Si la norme permet ou non n'est pas en question, mais comment un compilateur serait conforme à la norme. Je peux penser à une règle YACC pour vérifier ce citation de lettres de devis syntaxiquement ou un lex regexp pour faire le travail \ "[ az] * \ " (version simplifiée, bien sûr). Maintenant, est-ce qu'un Lex ou une erreur de syntaxe dépend de la mise en œuvre? Ou bien, nous pourrions tous être d'accord?
@DR Beco: ABC
Je suis d'accord. La version simplifiée que j'ai utilisée était juste pour indiquer que Lex peut correspondre aux citations. Le vrai est vraiment complexe, par exemple, il peut reconnaître "ABC \
Fondamentalement tout ce qui n'est pas conforme à l'ISO C 9899/1999, l'annexe A.1 "grammaire lexicale" est une défaillance lexicale si le compilateur fait son analyse lexicale selon cette grammaire. Voici quelques exemples: où EOF est la fin du fichier.
Je ne pense pas que 0x0g est une faute lexicale. Je pense que c'est deux jetons. Il produit probablement toujours une erreur syntaxe avec g comme nom de variable.
Lorsque vous reconnaissez le début d'un littéral octal par un 0 précédent et attendez-vous à faire correspondre la regex 0 [0-7] * , je pense que c'est.
Sorties GCC 3.4.5: chiffre non valide "9" en constante octale
Le problème ici est que GCC ne dit pas le genre d'erreur. Je comprends que les erreurs de position sont détectées par l'analyseur, pas l'analyseur lexical. Mais lisant la définition de jeton d'hexa et octal, je peux convenir que ces deux sont vraiment des erreurs Lex. Je suis toujours mal à l'aise avec ça.
@Ira 0x0G est un jeton de préprocesseur unique selon la norme.
@JIM: vraiment? Wow. Cela semble muet. D'une utilisation possible pourrait-elle être? Cela dit-il aussi 0xgzn est un seul lexeme? J'aurais attendu que 0X nécessiterait uniquement des chiffres hexagonaux de fin, de la même manière que 1. Nécessite uniquement des chiffres décimaux de fin. (Sûrement cela ne dit pas que 1.g est un seul lexeme?)
@Ira Oui, c'est un seul numéro PP tel que défini par la norme. La raison est de permettre aux préprocesseurs de pouvoir analyser simplement des jetons sans connaître la syntaxe complète des chiffres C. Fait intéressant, la syntaxe des numéros de PP comprend ce qui était utilisé pour être des expressions valides telles que 1E-x ... Le Comité n'a pas compris cela avant la dernière minute et essaya de trouver un correctif mais n'a pas pu faire donc. J'ai voté contre y compris ce problème dans la langue, mais la majeure partie du comité estimait que ce n'était pas important.
@JIM: Je suis désolé de votre perte: - {Franchement, de toutes choses à craindre dans le préprocesseur, la syntaxe numérique aurait été sur ma liste. De toutes les choses que nous savons comment lex ...
@Ira Oops, j'ai eu l'exemple d'une expression invalide erronée. L'étui d'angle est quelque chose comme 0xe-2 qui est une erreur de syntaxe plutôt que d'une expression avec la valeur de 12.
@Ira Vous devez comprendre que X3J11 a été dominé par des vendeurs de compilation de référence ...
@Ira m (0x, 2) est une erreur car 0x n'est pas une constante hexagone valide, mais m (0xe, 2) est en effet Legal tandis que 0xE-2 n'est pas.
Constante de flottante mal formée (E.G. 123,34E ou 123.45.33 ).
Hum ... La notation scientifique est très originale! Merci.
'ABC' est un élément lexical bien défini. Voir la définition des constantes de caractères dans la norme.
ID illégal
while (0) {}
OP a demandé des erreurs lexicales . "int 3d = 1" a les lexemes légaux "INT", "3", "D", "=", "1". "#defune" est traité comme deux lexemes "#", "Défune"; Ce dernier pourrait être illégal. Les mot-clés et les mots clés mal orthographiés sont des erreurs de syntaxe et non des erreurs lexicales.
ne sont pas [@ $ `] et d'autres symboles comme celui-là (peut-être d'unicode) erreurs lexicales en C si mis n'importe où en dehors de la chaîne ou du commentaire? Ils ne constituent pas une séquence lexicale valide de cette langue. Ils ne peuvent pas passer le lexer parce que le Lexer ne peut pas les reconnaître comme une sorte de jeton valide. Habituellement, les lexers sont basés sur FSMS ou Regex, de sorte que ces symboles ne sont que des entrées non reconnues.
Par exemple, dans le code suivant, il existe plusieurs erreurs lexicales: Nous pouvons le supporter par L'alimentation de ceci à GCC, qui donne GCC est intelligent et que la récupération d'erreur est donc une définition de fonction (elle sait que nous sommes dans "Main") mais ces erreurs définitivement ressemblent à des erreurs lexicales, elles ne sont pas des erreurs de syntaxe et à juste titre. Le LXER de GCC n'a pas de types de jetons pouvant être construits à partir de ces symboles. Notez qu'il traite même un symbole de trois octets utf-8 comme trois symboles non reconnus.
Erreurs lexicales:
0xe-2 , qui ressemble à une expression, mais est en fait une erreur de syntaxe selon la norme - un étui d'angle impair résultant des règles de pp-jetons.