Existe-t-il un comportement défini pour gérer un débordement de pile? En plus de terminer le processus, il ne semble pas y avoir beaucoup à faire. Je me demande simplement si quelqu'un sait ce que la norme C a à dire à ce sujet.Est-ce que le standard C définit un comportement de dépassement de pile?
La norme ne nécessite pas l'utilisation d'une pile et n'a rien à voir avec les débordements de pile.
Je suis assez sûr que les détails de ce qui se passe sont définis par le système d'exploitation, mais dans tous les cas, le programme devrait quitter. Vous avez raison de supposer qu'il n'y a vraiment rien que vous puissiez faire une fois qu'un débordement de pile se produit (au moins en tant que programmeur). Tout ce que vous pouvez vraiment faire est de les empêcher de se produire en premier lieu.
Cela dépend du système d'exploitation. Cependant, de nombreux systèmes d'exploitation autorisent l'écrasement de la taille de la pile par défaut. Par exemple, sous Windows, vous pouvez utiliser this linker flag pour augmenter la taille de la pile de 1 Mo à une valeur supérieure.
La norme C ne définit même pas une pile, elle ne définit donc certainement pas ce qui se passe lorsque la pile déborde.
Selon certaines réponses à this question, les normes C n'ont même rien à dire sur l'existence d'une pile, sans parler d'un débordement de pile.
La norme C99 ne définit pas de pile; il ne traite que du stockage automatique ou alloué dans l'abstrait, alors qu'une pile contiguë avec détection de débordement n'est qu'un mécanisme pour implémenter le stockage automatique.
Section 7.14 de la norme définit SIGSEGV comme le signal qui se produit sur "un accès invalide au stockage". Les implémentations de C ne sont pas nécessaires pour générer des signaux, mais les implémentations utilisant une pile de taille fixe contiguë * signalent typiquement SIGSEGV si un dépassement de pile est détecté.
Vous pouvez enregistrer une fonction de gestionnaire de signal pour SIGSEGV, mais elle ne peut pas retourner - "[i] f et lorsque la fonction revient, si la valeur de sig est SIGFPE, SIGILL, SIGSEGV, ou toute autre implémentation- valeur définie correspondant à une exception de calcul, le comportement [u] r est indéfini ".
(* pas que j'ai sciemment travaillé avec des implémentations C qui ne le font pas, mais je ne connais rien dans la norme C qui empêche l'utilisation des techniques courantes utilisées pour implémenter des domaines de stockage automatique extensibles dans d'autres environnements)
Comme d'autres personnes l'ont mentionné, la norme ne dit rien sur une pile. Mais, je pense que ce serait de définir le comportement de débordement de la pile, la norme dirait que cela entraîne un comportement indéfini.
:: rimshot ::
Les réponses ici sont raison de dire qu'il n'y a rien à voir avec la norme c mais votre déclaration selon laquelle « En dehors de terminer le processus, il ne semble pas comme il y a un ensemble beaucoup qui peut être fait "n'est pas - en général - vrai. En effet, sur la plupart des systèmes avec gestion de la mémoire virtuelle et pagination à la demande, la pile allouée est assez petite (typiquement 4Ko de plus qu'utilisée actuellement) et déborde souvent (ce qui génère une interruption de défaut de page) et l'OS ajoute une autre page de mémoire à la pile pour le fil.La limite de pile de - typiquement - 1MB, est juste une figure assez arbitraire choisie pour se prémunir contre les programmes d'emballement et n'est généralement pas une limite absolue (bien que c'était sur certains modèles de mémoire avec les processeurs Intel IIRC). Il ne serait généralement pas logique d'allouer 1 Mo de mémoire physique à chaque thread.
Sur certains systèmes, l'obtention d'une faveur prévisible après un dépassement de pile ajouterait une charge considérable à chaque appel de fonction; ainsi, la norme considère raisonnablement raisonnablement le débordement de pile comme un comportement indéterminé. Ceci est tout à fait approprié si l'objectif est de maximiser l'efficacité avec laquelle une implémentation peut exécuter des programmes légitimes.
La norme n'exige pas non plus que les systèmes disposent d'une pile suffisante pour prendre en charge des appels de fonctions non triviaux. Étant donné que certains programmes utiles (en particulier dans le monde des systèmes embarqués) peuvent se débrouiller avec moins de 16 octets de pile, et ne peuvent pas nécessairement être en mesure d'épargner plus de RAM que cela, exiger une pile généreuse viole la philosophie de ne payez pas pour ce dont vous n'avez pas besoin ". Malheureusement, le fait qu'un programme ne puisse pas dire quel type de profondeur il requiert, ni quelle sorte de pile est disponible, les seuls programmes qui peuvent être garantis ne pas s'engager dans un comportement indéfini sont: ceux dont l'utilisation de la pile est inférieure aux garanties minimales; En dehors du monde des systèmes embarqués, cela signifie que la norme ne garantit rien d'un programme plus grand qu'un jouet.
La norme C est contradictoire à cet égard. Considérez le programme suivant:
void foo(uintptr_t n)
{
int a;
printf("%p\n", (void *)&a);
if (n+1) foo(n+1);
}
int main()
{
int a;
printf("%p\n", (void *)&a);
foo(0);
}
Ce programme est tout à fait conforme et ne viole aucune des limites de traduction minimales, et comme d'autres l'ont dit, il n'y a rien dans la langue de la norme sur les limites pile/débordement. Cependant, il produit UINTPTR_MAX +2 objets a (à chaque niveau d'appel), dont les durées de vie se chevauchent toutes, chacune avec des adresses distinctes. Ceci est impossible par un simple argument de comptage.