Vérification d'une allocation statique

Bonjour,

J'aimerais savoir comment vérifier que la création d'une variable s'est bien faite ?
Je m'explique:

J'ai remarqué avec un programme bateau que la stack était limité à 15 Mo.

Code:

---

1 2 3 4 5 6

int main(void) { int a[3 000 000]; a[0] = 0; }

---

output-> segmentation fault

Je présume que c'est modifiable mais là n'est pas la question.

J'aimerais savoir comment je peux vérifier qu'un char tab[100] s'est bien créé. Je peux bien sûr allouer dynamiquement mais ça implique de libérer cette mémoire et on perd en performance.

Merci d'avance :)

Bonsoir,

une allocation sur la pile se passe bien si tu n'as pas de segfault :) ok, c'est une réponse bateau, mais c'est exactement ça : si l'allocation échoue ton programme segfault et tu ne peux rien y faire, c'est un signal que tu ne peux intercepter.

Citation:

---

Envoyé par nsvir

J'aimerais savoir comment je peux vérifier qu'un char tab[100] s'est bien créé. Je peux bien sûr allouer dynamiquement mais ça implique de libérer cette mémoire et on perd en performance.

---

Pour compléter ce que dit kwariz, non seulement il n'y a pas de « constructeur » comme dans d'autres langages de plus haut niveau mais cela ne fait pas non plus appel à un dispositif particulier : le pointeur de pile est simplement décrémenté pour laisser la place aux variables qui doivent s'y trouver et la taille comme l'emplacement des variables par rapport à l'état initial du pointeur (sauvegardé dans EBP sur IA32) est calculée à l'avance par le compilateur (sauf VLAs).

En ce sens, le programme en lui-même est valide. Si ton système d'exploitation t'a alloué moins de place que tu n'en réserves dans la pile, un accès à ton tableau va taper en dehors de la zone allouée exactement de la même façon que lors d'un banal dépassement de tableau.

Citation:

---

Je présume que c'est modifiable mais là n'est pas la question.

---

C'est surtout qu'il ne faut pas le faire : la règle en programmation est d'être aussi sobre que possible avec la pile. certaines personnes bannissent purement et simplement les passages par valeur d'arguments autres que des types natifs (idem pour la valeur de retour d'une fonction), et il existe même un flag spécial sur les compilateurs tels que GCC pour déclencher des warnings lorsque c'est le cas.

Je trouve ça très excessif mais 15 Mo pour un tableau local, c'est l'extrême inverse.

Citation:

---

Envoyé par kwariz

si l'allocation échoue ton programme segfault et tu ne peux rien y faire, c'est un signal que tu ne peux intercepter.

---

Techniquement si et il existe même une bibliothèque mais chut ! On ne va pas se mettre à ouvrir la boîte de Pandore, et surtout pas à ce stade. ;-)

Merci pour vos réponses!

Citation:

---

les passages par valeur d'arguments autres que des types natifs

---

Qu'entends tu par des types natifs ?

Citation:

---

la règle en programmation est d'être aussi sobre que possible avec la pile.

---

J'en conclus qu'il faut utiliser le moins possible la pile ? Donc pas de récursivité ni de déclaration de tableau ou de structure ?

Citation:

---

Envoyé par nsvir

Qu'entends tu par des types natifs ?

---

Les types prédéfinis du C (int, char, float, etc.) par opposition à ceux que tu définis toi-même soit en construisant des structures, soit en faisant des aliases avec typedef.

Citation:

---

J'en conclus qu'il faut utiliser le moins possible la pile ? Donc pas de récursivité ni de déclaration de tableau ou de structure ?

---

Non, pas à ce point-là. Et ce serait vraiment dommage de se passer de récursivité. En outre, tu peux très bien utiliser la pile comme tu le sens si tu es sûr de rester dans les limites et que tu as vérifié à l'avance qu'immobiliser une certaine taille ne va provoquer aucun effet secondaire.

Par contre, beaucoup de programmeurs débutants allouent directement des tableaux de taille invraisemblables directement dans la pile simplement parce que c'est plus simple que de faire un malloc() + free().

D'accord merci.

Vue que tu parles de typedef. J'ai entendu dire que c'était pas anodin pour l'optimisation du programme de faire des typedefs.

Je voulais donc savoir si c'était juste le compilo qui remplacait, (a la hauteur d'un define) ou si ça changeait l'execution du binaire.

C'est le compilo qui change les types et les vérifie du même coup... rien de changé à l'exécution.

Bonjour,

Citation:

---

Envoyé par nsvir

[...] J'ai entendu dire que c'était pas anodin pour l'optimisation du programme de faire des typedefs.

---

Ce que tu as entendu dire est faux ; les alias de type apportent simplement de l'information sémantique, à destination de ceux qui écrivent ou maintiennent le code. À priori, cela n'a pas d'influence directe sur la rapidité d'exécution (si c'est bien ce que tu entends par « optimisation du programme »).

Citation:

---

Envoyé par nsvir

Je voulais donc savoir si c'était juste le compilo qui remplacait, (a la hauteur d'un define) ou si ça changeait l'execution du binaire.

---

Comme dit plus haut, ça ne devrait rien changer à l'exécution du binaire (du moment que les types sous-jacents sous les mêmes, évidemment). En fait ça va même plus loin : toutes les informations de typage n'existent plus à l'exécution (disons, sur une implémentation typique du langage, sans parler des architectures dites « taguées », donc). Le compilateur est libre d'insérer dans le code machine généré quelques bouts de code permettant d'effectuer proprement les conversions, mais, comme dans la plupart des langages au typage statique, on ne se préoccupe plus de ces informations lors de l'exécution. C'est un gain en espace mémoire qui n'est pas négligeable.

On notera que la directive #define provient du préprocesseur ; elle est donc gérée antérieurement à la compilation (au sens propre du terme). D'autre part, la portée syntaxique d'une définition de type avec une telle primitive est différente ; il faut bien comprendre que le préprocesseur n'est pas forcément fait pour faire des alias de type. Vulgairement, il faudrait le comprendre comme une boîte noire très bête qui ne fait que des copiés/collés. Ça pose notamment des problèmes quand on commence à toucher aux alias de pointeurs, et, d'un point de vue plus pratique, quand on veut gérer plus finement la portée de ses types (car on peut donner une portée au bloc avec typedef, ce qui est plus simple à gérer que des enchaînements de #define et #undef). C'est différent de l'analyse du compilateur, qui se fait, elle, plus en profondeur. Mais, ça, c'est une autre histoire.

Bonne journée !

Merci pour ta réponses très complete!