Discussion :

[backlash]

Bonsoir,

Soit le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
int g(void)
{
    int ret = 1;
    return ret;
}
 
void f(int n)
{
    int m;
    int o = g(); /* (1) */
    int p;
}

Est-ce que la ligne commentée (1) a un impact sur la création de la pile de la fonction f lors d'un appel cette fonction f ?

[Kirilenko]

Bonsoir,

La pile contient les variables locales déclarées dans ta fonction. Sur une architecture basique, comme x86, la fonction manipule, non pas une pile à part entière, mais un cadre de pile, qui symbolise une partie de la pile elle-même. En conséquence, l'appel de la fonction g va modifier la valeur contenue dans une adresse du cadre de pile. En pratique, cependant, les variables seront sûrement manipulées à partir des registres.
Peut-être pourras-tu nous éclairer un peu à propos sur ta demande, afin que nous précisions un peu plus nos propos.

Bonne soirée.

[backlash]

En fait je voulais en venir au fait que :

1) est-ce que l'appel à g qui elle même doit avoir sa propre pile va impacter la taille de la pile de f (vu sa position dans le code) ?

2) ou est-ce que la pile est d'abord dimensionnée (complètement) pour stocker les variables locales, paramètres, adresse de retour et valeur de retour de f (avec les variables locales non initialisées), puis une fois cette pile créée la variable o est initialisée par appel à la fonction g?

3) est-ce que la norme ISO C précise comment doit être géré la déclaration d'une variable locale directement suivi d'une initialisation par appel de fonction ? ou est-ce implementation-dependent ?

[Kirilenko]

1) est-ce que l'appel à g qui elle même doit avoir sa propre pile va impacter la taille de la pile de f (vu sa position dans le code) ?

Dans le cas général et théorique, non. Les deux fonctions ont leur cadre de pile propre, qui est initialisé en début de fonction, et, suivant la convention d'appel, détruit en fin de fonction. Maintenant, dans la pratique, le compilateur sera sûrement capable d'inliner la fonction g, et donc d'affecter directement 1 à o.

2) ou est-ce que la pile est d'abord dimensionnée (complètement) pour stocker les variables locales, paramètres, adresse de retour et valeur de retour de f (avec les variables locales non initialisées), puis une fois cette pile créée la variable o est initialisée par appel à la fonction g?

On va dire que c'est plutôt de cette manière. Ceci dit, il n'y a pas vraiment dimensionnement à proprement dit (la taille de la pile est fixe, à part quand on utilise quelques subterfuges), mais juste un ajustement du pointeur de pile. Tu peux le vérifier avec le code assembleur produit (syntaxe AT&T) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
g:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$16, %esp
	movl	$1, -4(%ebp)
	movl	-4(%ebp), %eax
	leave
	ret
f:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$16, %esp
	call	g
	movl	%eax, -8(%ebp)  # 
	leave
	ret

3) est-ce que la norme ISO C précise comment doit être géré la déclaration d'une variable locale directement suivi d'une initialisation par appel de fonction ? ou est-ce implementation-dependent ?

Le C est avant tout quelque chose de portable ; il supporte donc des architectures exotiques, dont le modèle mémoire est différent de la pile, entre autres. Ce genre de détails est défini par l'ABI et par le compilateur ; c'est-à-dire, dans le formalisme normalien, par l'implémentation.

[backlash]

Merci Kirilenko

[Médinoc]

Au passage, le standard C définit-il une taille minimale de pile?
Pour l'instant, le plus proche que j'ai vu est "127 arguments in a function call"...