Discussion :

[__NR_nass]

Bonjour,
ceci est mon premier post ! je suis débutant en C, et je rencontre un problème totalement absurde que je n'arrive pas à m'expliquer.
Je suis sous Linux (ordinateur Intel Pentium, normal quoi) et j'utilise gcc pour la compil

Voilà mon programme. Je déclare dans une fonction deux tableaux de caractères, de 3 et 5 caractères par exemple.

Code :

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

1
2
3
4
5
6
7
8
void fonction(int a, int b, int c) {
   char tab1[3];
   char tab2[5];
}
 
int main() {
 fonction(1,2,3);
}

Le tableau de 3 caractères (=3octets) va prendre 1 mot double (4 octets) en mémoire, tandis que le tableau de 5 va en prendre 2, puisqu'on arrondit toute allocation à un multiple de 32 bits (ou je me trompe ?)

j'ai pourtant une grosse surprise. pour vérifier ce que je viens de dire, je compile sans assembler:
# gcc -S -o exemple.s exemple.o
et voilà à quoi ressemble ma fonction :

Code :

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

1
2
3
4
5
6
fonction:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$40, %esp
	leave
	ret

40 octets alloués dans la pile !!
je rééssaie avec un seul tableau, de 4 caractères:

Code :

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

1
2
3
4
5
6
fonction:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$4, %esp
	leave
	ret

là, je suis d'accord.
voyons voir avec un seul tableau de 3 caractères?

Code :

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

1
2
3
4
5
6
fonction:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$24, %esp
	leave
	ret

Quel est le problème? Ça me laisse vraiment perplexe...

Nass

[Médinoc]

gcc a tendance à faire des trucs un peu "personnels" sur la pile.
Notamment pour certains appels de fonction, j'ai déjà vu gcc réserver à l'avance un gros buffer sur la pile et y mettre les paramètres, plutôt que les empiler au fur et à mesure...

[dapounet]

puisqu'on arrondit toute allocation à un multiple de 32 bits (ou je me trompe ?)

La taille totale de l'allocation doit être alignée par 4 donc on pourrait utiliser 8 octets pour les deux tableaux a priori. Réessaie en activant les optimisations pour être sûr que GCC fait du mieux qu'il peut. Il y a des fonctions optimisées comme strlen() qui traitent les octets quatre à quatre donc c'est peut-être intéressant que le dernier caractère soit aligné par 4 mais ça me paraît tiré par les cheveux...

gcc a tendance à faire des trucs un peu "personnels" sur la pile.
Notamment pour certains appels de fonction, j'ai déjà vu gcc réserver à l'avance un gros buffer sur la pile et y mettre les paramètres, plutôt que les empiler au fur et à mesure...

C'est inefficace sur les processeurs modernes d'ailleurs. Il alignait aussi la pile par 16 avant mais apparemment ça a changé.

[__NR_nass]

merci pour ces réponses

Réessaie en activant les optimisations pour être sûr que GCC fait du mieux qu'il peut.

comment? désolé, je suis plus dans l'assembleur pour l'instant (align 4)

ce qui m'a amené à poster ça c'est que j'ai lu un article où deux tableaux de 5 et 10 caractères étaient réservés, et en conséquence on avait 20 octets alloués, comme on pouvait s'y attendre...

[souviron34]

comment? désolé, je suis plus dans l'assembleur pour l'instant (align 4)

• gcc -O
• gcc -O2
• gcc -O3

[__NR_nass]

merci...
pas de changement de comportement cependant (même espace alloué).

[corrector]

C'est inefficace sur les processeurs modernes d'ailleurs.

Pourquoi ça?

[dapounet]

Parce que sur le Pentium M et le Core PUSH ne fait qu'une µop et que c'est plus court de passer les arguments normalement que d'adresser la pile indirectement. C'est la même chose pour le K10 :

http://www.amd.com/us-en/assets/cont...docs/40546.pdf

4.7 Stack Operations
Optimization
When saving or restoring registers in function prologues or epilogues, or when passing arguments through the stack, use PUSH or POP instructions to improve performance and to reduce code size.

Sinon pour revenir au problème, ce serait possible que l'espace mémoire en plus soit là pour les vérifications de sécurité à l'exécution ?