Une version plus récente du compilateur que celui utilisé par ce mauvais cours donne la réponse:
$ gcc -O3 c.c
c.c: Dans la fonction « main »:
c.c:5:9: warning: l'itération 4 invoque un comportement indéfini [-Waggressive-loop-optimizations]
tab[4-i]=0;
~~~~~~~~^~
c.c:4:1: note: dans cette boucle
for (i=1;i<6;i++)
^~~
$
Je trouve ça hallucinant de trouver ce genre de question dans un cours sur le C.
Tu peux répondre à ton prof qu'un dépassement de tableau c'est un comportement indéfini en C, ou undefined behavior. On ne sait pas ce que ça fait, parce que la norme C ne spécifie pas.
En l'occurence, selon le compilateur, les optimisations utilisées, voire même l'architecture (stack descendante vs stack montante), tu n'auras pas de boucle infinie.
Ceci dit je suppose que la réponse attendue est que tu vas taper à l'adresse mémoire (tab - 4) (en supposant qu'un int vaut 4 octets), c'est à dire la variable i
Je ne vois pas de boucle infini ici. J'y vois une ânerie et un programme qui va planter ou pas selon que le compilo voit venir..
Je pense comprendre ce qu'il essai de faire, mais il ne me semble pas que la contigüité des données déclarées soit garantie. Fort probable peut-être mais certain, non.
De plus, une bonne pratique serait de déclarer i au sein de la boucle, donc ça tombe à l'eau.
Il y a d'autres moyens de mettre en évidence les effets de bord, parce que je suppose que c'est ce dont il s'agît ici. D'autant plus que ces effets sont rarement prédictibles. Penser en prévoir les effets et pire, essayer d'en tirer parti, n'est rien d'autre que de la loterie.
Tout comme les autres, je vois ici un programme instable, avec aucune garantie que ça produise une boucle infinie.
Alors dans les faits, oui, souvent les variables locales sont empilées dans un ordre qui fait que déborder du tableau tab flinguera la variable d'avant, donc i, et donc en débordant, on modifiera i. Et si on lui met une valeur 0 on partira en boucle infinie.
Mais c'est indéfini, et ça pourrait très bien faire autrement avec un autre compilateur, ou même avec une autre version.
Mais la question consiste à regarder ce qui se passe exactement sur les machines indiquées, avec la version du compilo etc. Ce n'est pas une question de programmation en C. Et personne ne dit que ce code est correct.
Evidemment qu'il s'agit d'un UB. Il s'agit de préciser ce qui se passe dans cet UB, dans les conditions indiquées (et probablement examinées pendant les TP).
Donc
en rentrant dans main() un "cadre" est alloué pour sauver des trucs (registres), et stocker les diverses variables locales
il contient le tableau
en shootant à coté du tableau on flingue des données, genre l'adresse de retour
et forcément, si on veut se servir de cette adresse pour rentrer à la maison, on a un problème.
Maintenant, plus précisément, il faut voir la structure exacte du cadre de pile avec les options de compilations.
Si tu veux une analogie, c'est un peu comme si tu étais assis sur un bureau, que tu avais une feuille devant toi qui fait 5 case, et un petit post-it de une case.
Si tu écris dans le tableau, donc sur ta feuille de 5 cases, et que tu débordes, alors tu écris sur le bureau... ou sur ce qu'il y a sur le bureau...
Et ton prof part du principe que le post-it est posé juste à droite de la feuille de 5 cases... Mais si c'est organisé autrement et que le post it est posé ailleurs, alors ça fait n'importe quoi...
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Bonhomme !! | Jeu de plateforme : Prototype.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html