Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C (Pour experts) Problème de syntaxe dans un switch()

(Pour experts) Problème de syntaxe dans un switch()

14 réponses
Avatar
Patrick 'Zener' Brunet
Bonjour.

Ce qui suit résulte d'expériences visant à construire un système de macros
pour un générateur de code "assez bête" par empilage de structures
stéréotypées... Donc ceci n'est pas à considérer comme un apprentissage
humain...

Le but serait d'obtenir quelque chose ressemblant à ça:

BLOC
{
code normal;
BLOC
{
/* ici code interdit; */
ENTETE( arguments)
code normal;
}
code normal;
}

et satisfaisant les contraintes suivantes :
- il est possible de ne pas avoir d'ENTETE() dans un BLOC, que du code
normal
- s'il y en a un, alors il doit se trouver au tout début du BLOC
- il ne peut pas y avoir d'autre ENTETE() dans le même BLOC, la création
d'un BLOC imbriqué est obligatoire
- ENTETE() peut produire un break; et donc BLOC doit avoir une syntaxe selon
laquelle ce break; fait sortir du BLOC
- BLOC n'est pas une boucle, le code contenu est exécuté une seule fois.

Je souhaite que tout code mal formé produise des erreurs de syntaxe C qui le
rendent incompilable.

Les solutions mises en oeuvre sont les suivantes :

#define BLOC switch( *(( int *) _pE))
où _pE est une variable de type int * existante dans le système

#define ENTETE( arguments) \
default: \
char ForceBloc = 0; \
/* traitement utile */ \
if( _pE != 0) \
break;

En désactivant localement le warning du compilo pour les switch() vides,
toutes les conditions sont remplies, à l'exception de la deuxième, et là je
suis très étonné parce que ça donne :

switch( *(( int *) _pE))
{
/* ici code interdit qui est pourtant accepté */
default:
char ForceBloc = 0;
/* traitement utile */
if( _pE != 0)
break;
code normal ;
}

A part l'initialisation d'une variable déclarée localement, donc un :
char * Test = "zut !"; // => erreur "initialisation skippée par le
default:"
... tout code semble acceptable en entrée du switch, avant le "default:" !!!

Est-ce un bug de mon compilateur (celui de VC6), où existe-t-il une
sémantique qui l'explique ?

Auriez-vous une idée qui puisse prendre place dans ces macros et qui
interdise tout code à cet endroit (sans pour autant imposer la présence d'un
ENTETE() dans un BLOC ?

Il est envisageable si c'est nécessaire que les macros embarquent l'accolade
ouvrante (des macros de fermeture seront alors fournies pour l'homogénéité.

Merci de vos conseils.
Cordialement,

--
/***************************************\
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
\***************************************/
Signaler un problème avec ce contenu

4 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Antoine Leca
En <news:427f9cbb$0$316$,
Patrick 'Zener' Brunet va escriure:
En <news:427ba6b8$0$318$,
Patrick 'Zener' Brunet va escriure:
J'ai regardé les deux exemples de code :


Pardon, je ne comprend plus. Quels deux exemples?

Donnés dans les pages dont vous avez fourni le lien dans votre

première intervention (et qui se recoupent).


Mais je ne vois qu'un seul exemple (l'autre morceau de code, celui qui est
« lisible », n'est qu'une explication de ce que c'est sensé faire le truc).
Le seul qui est « intéressant », c'est celui avec

switch(count%2)
case 0: do{ *to = *from++;
case 1: *to = *from++;
}while(--n>0);


avec donc des sauts directement au milieu d'une instruction, donc une
instruction qu'à première vue on pourrait penser être exécutée (le 1er =, le
case 0), ne l'est pas forcément.
Et évidemment c'est pareil avec les déclarations, surtout en C99.


Oui, je veux bien, mais il me semble bien (surtout après l'histoire
du if(0) plus bas) que ce code est équivalent conceptuellement - et
au mieux - à celui-ci :

if( 0)
{
code interdit ici;
}



Bin c'est bien cela le problème, ce code n'est surtout pas interdit (on s'en
sert souvent pour dégager un gros bloc de code, mais en gardant le bénéfice
de la vérification syntaxique, que #ifdef ne fait pas).


D'où la question : comment a-t-on pu normaliser ça sans avoir fumé
des trucs bizzares avant ?


Tout simplement (?) à cause de la volonté (de D. Ritchie) de simplifier le
parseur initial; et tant pis si cela fait qu'il y a des trucs ambigus, C
n'est pas Ada et ne cherche pas à le concurrencer.


Par exemple, tu laisses une construction (déclaration ou instruction)
ouverte, c'est-à-dire sans le point-virgule dans BLOC; et tu la
fermes dans ENTETE. Comme cela, si on te rajoute quelque chose au
milieu, cela va générer des erreurs de syntaxes (incompréhensibles,
mais là c'est un autre problème).


Non, ça c'est pas bon parce qu'un BLOC peut aussi ne pas contenir
d'ENTETE() et seulement du code normal.


Ce n'est pas un souci, il suffit que le FIN_BLOC() contienne le ; (ou autre)
adéquat pour fermer la déclaration.


Antoine



Avatar
Patrick 'Zener' Brunet
Bonjour.

En <news:427f9cbb$0$316$,
Patrick 'Zener' Brunet va escriure:
En <news:427ba6b8$0$318$,
Patrick 'Zener' Brunet va escriure:
[...]



Par exemple, tu laisses une construction (déclaration ou
instruction) ouverte, c'est-à-dire sans le point-virgule dans BLOC;
et tu la fermes dans ENTETE. Comme cela, si on te rajoute quelque
chose au milieu, cela va générer des erreurs de syntaxes
(incompréhensibles, mais là c'est un autre problème).


Non, ça c'est pas bon parce qu'un BLOC peut aussi ne pas contenir
d'ENTETE() et seulement du code normal.


Ce n'est pas un souci, il suffit que le FIN_BLOC() contienne le ; (ou
autre) adéquat pour fermer la déclaration.



Toujours pas bon, parce qu'un BLOC peut aussi ne pas contenir
d'ENTETE() et seulement du code normal :
Ce code normal ne serait pas correctement placé parce qu'il faudrait
effectivement fermer la construction incomplète avant lui, pas après lui...
A moins que le code normal ne le soit pas et que sa première instruction
introduise elle-même la fameuse fermeture, ce qui reviendrait à créer une
macro remplaçante d'ENTETE() pour les cas où ENTETE() ne s'applique pas...
Là ça devient franchement môôôche.

Je crois bien qu'il n'y a pas de solution...

Cordialement,

--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/



Avatar
Antoine Leca
En <news:42850dbd$0$6254$,
Patrick 'Zener' Brunet va escriure:

Non, ça c'est pas bon parce qu'un BLOC peut aussi ne pas contenir
d'ENTETE() et seulement du code normal.


Ce n'est pas un souci, il suffit que le FIN_BLOC() contienne le ; (ou
autre) adéquat pour fermer la déclaration.



Toujours pas bon, parce qu'un BLOC peut aussi ne pas contenir
d'ENTETE() et seulement du code normal :


Euh ? Mais alors ton système devient impossible à analyser.

Résumé de ce que j'ai compris jusqu'à présent:
Après un BLOC(), tu peux avoir, soit ENTETE(), soit du code normal (et alors
ENTETE() devient «interdit»). Et tu veux de plus que s'il y a violation de
cette règle (apparition d'un ENTETE() concurremment avec du code juste après
BLOC()), ce soit considéré comme une faute de syntaxe au niveau du code.
Donc signalé bien avant. Pour moi c'est indécidable sauf à faire plusieurs
passes, ce qui revient à utiliser un outil de préanalyse ou un préprocesseur
différent.

Si l'on se restreignait à n'indiquer le problème qu'au niveau du ENTETE(),
c'est encore un souci si l'on veut utiliser le préprocesseur: celui-ci
n'ayant pas d'état accessible à l'utilisateur (sauf à utiliser #include), je
ne vois pas comment tu vas pouvoir signaler le "soit, soit" ci-dessus au
préprocesseur; sauf évidemment à avoir deux constructions, donc deux
versions de BLOC(), une suivie obligatoirement de ENTETE(), l'autre qui
n'inclue que du code.


Antoine



Avatar
Patrick 'Zener' Brunet
Bonjour.

En <news:42850dbd$0$6254$,
Patrick 'Zener' Brunet va escriure:

Non, ça c'est pas bon parce qu'un BLOC peut aussi ne pas contenir
d'ENTETE() et seulement du code normal.


Ce n'est pas un souci, il suffit que le FIN_BLOC() contienne le ;
(ou autre) adéquat pour fermer la déclaration.



Toujours pas bon, parce qu'un BLOC peut aussi ne pas contenir
d'ENTETE() et seulement du code normal :


Euh ? Mais alors ton système devient impossible à analyser.



Les deux structures possibles sont :

1) BLOC { <code> }
2) BLOC { ENTETE() <code> }

et le but était d'interdire :

3) BLOC { <code> ENTETE() <code> }

avec éventuellement une alternative de définition de BLOC embarquant les { }
et conduisant à :

4) BLOC2 ENTETE() <code> FIN_BLOC2

Le problème consistait donc à trouver un contenu pour ENTETE() et pour BLOC
ou BLOC2 qui simultanément :

- accepte un break; qui doit alors faire sortir du BLOC{ }
- exécute une fois et une seule tout le contenu du BLOC{ }
- autorise les formes 1 et 2 mais pas la forme 3

C'est à dire en fait trouver un élément de contenu à placer au début de
ENTETE() et qui soit obligatoirement (sous peine d'erreur de syntaxe)
premier élement d'un BLOC ou BLOC2,
... et donc comme il peut ne pas y avoir d'ENTETE() mais seulement du code C
normal, cet élément doit aussi être première instruction au sens de C d'un
bloc {} tel qu'utilisé pour constituer BLOC (ce qui élimine donc l'astuce de
la syntaxe incomplète répartie entre BLOC2 et ENTETE() ).

Je suis désormais convaincu que c'est impossible car C n'admet pas à ma
connaissance de telle "première instruction", surtout depuis que les
déclarations de variables sont acceptées en milieu de code.

Merci de votre sagacité, mais il faut savoir se contenter d'un résultat
juste suffisant. Il s'agit d'un code intermédiaire qui sera utilisé
temporairement dans une phase de boot-strapping, et plus tard régénéré
automatiquement. Donc il suffira d'être prudent dans cette première phase
qui est traditionnellement non-sécurisée.

Cordialement,

--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/




1 2