Discussion :

[Gruik]

Salut,

Je me demandais comment on faisait pour savoir combien de taille de pile alloue gcc à un programme. Est-ce une taille fixe (et parametrable) ou bien il la determine tout seul en fonction des variables locales qu'il trouve?

Je crois savoir que les variables locales sans classe de mémorisation sont dites "automatiques" et d'apres moi, elles sont mises en "static" si le compilateur estime que yaura pas assez de place pour une telle variable dans la pile. Mais en fait j'en sais rien.

Est il possible de savoir ce que le compilateur fait des grosses variables locales? Car je crois qu'une taille typique de pile est de l'ordre de 2Ko, un buffer de 10Ko ne rentrerait pas.

Je cherche juste à faire des economies de memoire dans le segment de données et donc ces temps ci je privilegie la pile (buffers non static donc).

[Emmanuel Delahaye]

Je me demandais comment on faisait pour savoir combien de taille de pile alloue gcc à un programme.

Il n'y a pas de réponse portable, et c'est un vrai problème.

Est-ce une taille fixe (et parametrable) ou bien il la determine tout seul en fonction des variables locales qu'il trouve?

Ca déoend de l'implémentation. C'est souvent automatique, c'est à dire que la mémoire libre (le tas) est attaqué d'un coté par la pile et de l'autre par les malloc(). Il peut on non y avoir un contrôle... Ne pas compter dessus. Il peut aussi y avoir une pile par thread, par processus, par interruption... C'est très complexe et hors de la portée du programmeur C.

Je crois savoir que les variables locales sans classe de mémorisation sont dites "automatiques" et d'apres moi, elles sont mises en "static"

Euh non.
'auto' -> mémoire automatique (pile)
'static' -> mémoire statique

si le compilateur estime que yaura pas assez de place pour une telle variable dans la pile. Mais en fait j'en sais rien.

Ben non. Ca interdirait la récursion, les appels imbriquées, le multi-threads...

Est il possible de savoir ce que le compilateur fait des grosses variables locales?

local = auto. Si ça casse, c'est de la faute du programmeur. La mémoire allouée est là pour ça.

Car je crois qu'une taille typique de pile est de l'ordre de 2Ko, un buffer de 10Ko ne rentrerait pas.

Il n'y a pas de 'taille typique'. Ca peut aller de quelques bytes à plusieurs méga...

Je cherche juste à faire des economies de memoire dans le segment de données et donc ces temps ci je privilegie la pile (buffers non static donc).

Mauvaise idée. malloc()/free() sont tes amis dès qu'un objet local dépasse une 100aine de bytes (au pif).

[Gruik]

Merci pour ces eclaircissements.

Ce thread pourrait partir en debat "pour ou contre malloc" car je suis assez anti-malloc. Mais si tu dis que mettre de trop gros objets dans la pile engendre des especes d'allocations dynamiques, ça redore effectivement le blason du malloc.

Pourquoi je suis anti malloc
* C'est vraiment source de problèmes. Un free qu'on fait 2 fois, une lecture ou ecriture apres un free, un free qu'on oblie...
* S'amuser à tester le retour du malloc avec NULL rajoute de la complexité et allourdit le code. A t on vraiment envie de prevoir quelquechose si malloc echoue? Qui dans la salle a deja eu un malloc retournant NULL?
* On peut pas utiliser sizeof() pour connaitre la taille du tableau de caracteres alloué. J'utilise beaucoup sizeof() dans les snprintf, strncpy et fgets. (ca s'applique bien sur qu'aux tableaux de caracteres pour y mettre du texte, apres pour les objets, on peut toujours utiliser sizeof)

[fearyourself]

Pourquoi je suis anti malloc
* C'est vraiment source de problèmes. Un free qu'on fait 2 fois, une lecture ou ecriture apres un free, un free qu'on oblie...

Si on code correctement, ces problèmes n'en sont pas (remarque, si on met les pointeurs à NULL après un free, il n'y a plus de problème pour le double free). Et la lecture et écriture peuvent vérifier si le pointeur est encore valide (par rapport à NULL)...

Comme l'écrirait Emmanuel:

Code :

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

1
2
 
free(ptr) , ptr = NULL;

* S'amuser à tester le retour du malloc avec NULL rajoute de la complexité et allourdit le code. A t on vraiment envie de prevoir quelquechose si malloc echoue? Qui dans la salle a deja eu un malloc retournant NULL?

Moi, plus d'une fois... Travaille avec des grandes quantités de données et tu remarqueras que cela arrive fréquemment.

* On peut pas utiliser sizeof() pour connaitre la taille du tableau de caracteres alloué. J'utilise beaucoup sizeof() dans les snprintf, strncpy et fgets. (ca s'applique bien sur qu'aux tableaux de caracteres pour y mettre du texte, apres pour les objets, on peut toujours utiliser sizeof)

Je passe généralement une structure contenant la taille du tableau. En statique, j'utilise aussi un entier pour avoir la taille "effective" (vs les cases vides) donc de toute façon j'ai un entier...

Jc

[Franck.H]

Ce thread pourrait partir en debat "pour ou contre malloc" car je suis assez anti-malloc.

Il n'y a pas à être contre ou pour malloc, c'est des fonctions plus qu'essentielle du C, d'ailleurs, je ne pense pas qu'on puisse s'en passer, j'ai du mal à m'en rendre compte qu'on puisse programmer en C sans jamais utiliser malloc ou autre fonction de la meme famille

Franchement, s'il y'a bien un truc à maïtriser, c'est bien l'allocation dynamique et ce va de soi .... les pointeurs !

[Emmanuel Delahaye]

Ce thread pourrait partir en debat "pour ou contre malloc"

Je ne vois pas quels sont les arguments contre malloc(). On ne peut quasiment pas faire de programmation sérieuse, souple, auto-démerdante sans malloc(). Personnellement, c'est plutôt la mémoire statique que j'aurais tendance à éliminer.

car je suis assez anti-malloc. Mais si tu dis que mettre de trop gros objets dans la pile engendre des especes d'allocations dynamiques,

Non, des catastrophes !

ça redore effectivement le blason du malloc.

Pourquoi je suis anti malloc
* C'est vraiment source de problèmes. Un free qu'on fait 2 fois, une lecture ou ecriture apres un free, un free qu'on oblie...

Ca, c'est le B.A. BA. Si tu n'aimes pas malloc(), faut pas faire de C... Mais la gestion demande de la rigueur, et comme je ne suis pas un génie, je me suis fait un outil de vérification :

http://emmanuel-delahaye.developpez.com/clib.htm
Module SYSALLOC

qui est à la disposition de la communauté.

* S'amuser à tester le retour du malloc avec NULL rajoute de la complexité et allourdit le code. A t on vraiment envie de prevoir quelquechose si malloc echoue? Qui dans la salle a deja eu un malloc retournant NULL?

On voit que tu n'as jamais traité de gros blocs de données (plusieurs Mo), ni fait d'embarqué avec 128 ko de RAM...

* On peut pas utiliser sizeof() pour connaitre la taille du tableau de caracteres alloué.

Une structure {taille,adresse} fait l'affaire.

J'utilise beaucoup sizeof() dans les snprintf, strncpy et fgets. (ca s'applique bien sur qu'aux tableaux de caracteres pour y mettre du texte, apres pour les objets, on peut toujours utiliser sizeof)

Si tu es un adepte des tableaux de taille fixe, je comprends que tu aimes sizeof, mais dans la vrai vie, les tableaux fixes, c'est rare. Oui, il faut mémoriser et transporter adresse et taille. Rien de bien nouveau...

Pour te faire aimer malloc() :

http://emmanuel-delahaye.developpez.com/clib.htm

[Gruik]

( haha, comment ils sont furieux )

Hey, je dis pas qu'on peut se passer de malloc, je voulais dire que c'est pas parce qu'on sait faire de l'allocation dynamique qu'il faut l'utiliser à chaque fois.
J'ai été adepte du malloc, mais aujourd'hui je sais que le code le plus simple est le mieux.

[Emmanuel Delahaye]

Hey, je dis pas qu'on peut se passer de malloc, je voulais dire que c'est pas parce qu'on sait faire de l'allocation dynamique qu'il faut l'utiliser à chaque fois.
J'ai été adepte du malloc, mais aujourd'hui je sais que le code le plus simple est le mieux.

Je suis d'accord.

[Gruik]

^^

Bon j'ai posé la question sur la mailing list gcc ..
Si j'ai pensé que la pile était limitée en taille c'est parce que du temps de ma jeunesse ou j'utilisais borland c++, on pouvait choisir la "taille" de son executable et configurer je crois la taille de la pile
Et aussi, j'avais fait un peu d'assembleur (x86) et je me souviens qu'on pouvait definir la aussi les differentes tailles des segments et de la pile.

[Médinoc]

La pile est bel et bien limitée en taille.

Sous Windows par exemple, on spécifie la taille lors d'un CreateThread(), (ou à l'édition de lien pour le premier thread) et la taille par défaut fait 1 Mo.
Si on dépasse, on a droit à l'exception EXCEPTION_STACK_OVERFLOW (ce n'est pas une exception C++)

[Gruik]

Ok, merci, c'est ce qu'on m'a repondu aussi sur la mailing list.

La commande linux "limit" donne la taille de la pile pour tout programme et elle était de 8Mo pour moi.

[loufoque]

et comme je ne suis pas un génie, je me suis fait un outil de vérification :

autant utiliser valgrind.

[Emmanuel Delahaye]

et comme je ne suis pas un génie, je me suis fait un outil de vérification :

autant utiliser valgrind.

C'est portable ? On a le code source ? Ca marche sur des petites plateformes (embarqué) ? C'est indépendant de la lib c ?

[loufoque]

Ça marche uniquement sous linux x86, x86_64 et ppc.
Ça travaille directement avec les binaires, c'est indépendant du langage de programmation, donc a priori aussi de la libc.
Et c'est sous GPL.

Valgrind est une suite complète de qualité pour déboguer et profiler des programmes sous linux.

Si le programme n'a pas trop de code qui dépend de la plateforme, déboguer sous linux suffit.

[Franck.H]

Oui mais là ca reste surtout uniquement pour Linux, ce qui n'est pas top, pour ce genre de d'outils le must reste quand même la possibilité de portabilité !