Bof, moi la question que je me pose, c'est ce que dit la norme à ce sujet.
Que l'on accède à une variable hors de sa portée, c'est un cas d' undefined behavior.
If an object is referred to outside of its lifetime, the behavior is undefined. §6.2.4/2
C'est pourquoi ce code n'est pas un exercice de langage C.
Je le considère comme un exercice pour expliquer le mécanisme des fonctions et de leurs piles, voire de l'espace mémoire utilisateur.C'est même un classique.
De mon point de vue, c'est la raison pour laquelle il est important de savoir pourquoi la valeur de i est malgré tout déterminée sur les architectures/OS les plus courantes.
Le fait est que le C et le C++ doivent être les seul langages (sans intégrer directement de l'assembleur) dans lequel on peut écrire et compiler de telles choses.
Si elle ne dit rien, on a effectivement un comportement indéterminé
Au contraire, c'est parce qu'elle le dit que c'en est un. Cela aurait pu être unspecified ou implementation-defined voire invalide.
D'ailleurs, tu le dis toi-même, il semble que quand les optimisations sont activées, ça ne marche plus pareil
C'est plus que ça.
Les compilateurs vont faire ce qu'ils veulent de ce code, même sans optimisation.
Ils peuvent le réduire à :
[^] # Re: Décomposer les opérations
Posté par David Marec . En réponse au message Je ne comprends pas ce que fait cette fonction. Évalué à 2. Dernière modification le 31 octobre 2019 à 13:29.
Que l'on accède à une variable hors de sa portée, c'est un cas d' undefined behavior.
C'est pourquoi ce code n'est pas un exercice de langage C.
Je le considère comme un exercice pour expliquer le mécanisme des fonctions et de leurs piles, voire de l'espace mémoire utilisateur.C'est même un classique.
De mon point de vue, c'est la raison pour laquelle il est important de savoir pourquoi la valeur de
iest malgré tout déterminée sur les architectures/OS les plus courantes.Le fait est que le C et le C++ doivent être les seul langages (sans intégrer directement de l'assembleur) dans lequel on peut écrire et compiler de telles choses.
Au contraire, c'est parce qu'elle le dit que c'en est un. Cela aurait pu être unspecified ou implementation-defined voire invalide.
C'est plus que ça.
Les compilateurs vont faire ce qu'ils veulent de ce code, même sans optimisation.
Ils peuvent le réduire à :
si ça leur chante.
Mais on sort du sujet de l’exercice, AMHA.