Discussion :

[hbx360]

Bonjour,

Je voudrai savoir si déclarer un pointeur dans une fonction et en utilisant malloc peut-être correcte sachant que toutes variables déclarées dans une fonction est détruite à la fin.

Est-ce que faire ceci est correct (code au plus simple):

Code :

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

1
2
3
4
5
6
7
 
char *ptr maFonctionQuiDéclareUnPtr()
{
    char *ptr = malloc(1000);
    ....
    return ptr;
}

Pourriez-vous me dire si c'est juste ?
Même si ptr qui est déclaré dans la fonction, soit supprimé à la fin de celle-ci, du fait que malloc est été invoqué, alors l'adresse renvoyé par le return est toujours valide.

[gerald3d]

Bonjour.

Effectivement toute variable déclarée dans une fonction est détruite lors de la fin d'exécution de cette dernière. Mais ici tu utilises malloc(); qui va allouer un bloc mémoire dans le tas. C'est à dire en dehors de toute fonction. Donc en retour tu vas obtenir le pointeur de ce bloc mémoire non détruit. Ta fonction est donc toute à fait correcte.

[Sve@r]

Bonjour

Même si ptr qui est déclaré dans la fonction, soit supprimé à la fin de celle-ci, du fait que malloc est été invoqué, alors l'adresse renvoyé par le return est toujours valide.

Exact.
La variable "ptr" est détruite effectivement... mais sa valeur (qui contient l'adresse de la zone allouée) est renvoyée à l'appelant qui lui peut la récupérer et la traiter.

C'est exactement la même chose que dans cet exemple

Code c :

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

1
2
3
4
unsigned int carre(int n) {
    unsigned int r=n*n;
    return r;
}

Certes "r" est perdue, mais sa valeur elle a été renvoyée donc pas de souci (enfin vis à vis de la fonction car si l'appelant, lui, ne la récupère pas c'est son problème).

En fait il ne faut pas confondre "variable perdue" et "valeur perdue". Comme le dit gerald3d, l'allocation se fait dans la zone mémoire appelée "tas (de m...)". Cette allocation est gérée entièrement par les fonctions de type alloc. Ensuite l'adresse de la zone allouée est renvoyée par malloc() et tu la récupères dans "ptr"... puis toi-même tu renvoies ensuite cette valeur. Donc c'est "passe à ton voisin" et tant que tu ne perds pas cette valeur tout va bien.

D'ailleurs ta fonction a tellement peu de différence avec la fonction malloc (qui elle-aussi est une fonction comme une autre avec ses variables internes détruites elles-aussi à sa fermeture) qu'elle peut se contenter de renvoyer directement son retour. Toutefois le but de ta fonction n'est pas de déclarer un pointeur (ça ne veut rien dire) mais d'allouer une zone et renvoyer son adresse. Donc un petit changement de nom s'impose...

Code c :

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

1
2
3
char *ptr maFonctionQuiRetourneAdresseZoneAllouee() {
    return malloc(1000);
}

[hbx360]

D'accord merci pour vos réponses.

Mais pourquoi dire :

Bonjour

"tas (de m...)".

[Sve@r]

Mais pourquoi dire :

Comme ça tu n'oublieras jamais le nom de cette zone mémoire : le tas.

[hbx360]

Ah d'accord

[gerald3d]

Histoire d’être complet dans la terminologie la mémoire allouée pour une fonction s’appelle la pile.

En générale cette pile fait 1Mo. Elle peut être différente selon ta machine. Il est important de savoir qu’elle a une taille finie. Si tu déclares un tableau par exemple dont la taille est supérieure à la pile tu auras droit à un joli plantage de ton application 😁.

[WhiteCrow]

Tas (heap) et pile (stack) sont les deux zones mémoires les plus citées pour les plateformes usuelles en C. Il faut garder en mémoire (pun intended) qu'il existe également deux autres zones importantes : la zone où sont allouées les variables globales (zone en read/write) qui initialisées au lancement du programme contrairement aux variables des autres zones, ainsi qu'un zone en read only qui permet de stocker les littéraux (les chaînes littérales par exemple ou d'autres constantes mais pas en C, sauf si on le fait explicitement en utilisant des extensions des compilos).
À ces zones s'ajoutent aussi les portions mémoires allouées aux bibliothèques dynamiques, au kernel et toute autres zones spécifiées lors du link time (il y en a pour les symboles de debug) … bref il y en a toute une floppée suivant l'os, la plateforme, …
On peut limite parler également des caches processeur voire des registres, mais ces derniers ne rentrent en général pas dans la description d'un modèle mémoire à la C.

Sous Linux, un programme quelconque peut toujours avoir accès lisiblement à sa map mémoire via le fichier virtuel /proc/self/map ; par exemple avec cat

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
17
18
19
20
21
22
23
24
25
26
$ cat /proc/self/maps 
555f82ffb000-555f82ffd000 r--p 00000000 08:12 6818382                    /usr/bin/cat
555f82ffd000-555f83002000 r-xp 00002000 08:12 6818382                    /usr/bin/cat
555f83002000-555f83005000 r--p 00007000 08:12 6818382                    /usr/bin/cat
555f83005000-555f83006000 r--p 00009000 08:12 6818382                    /usr/bin/cat
555f83006000-555f83007000 rw-p 0000a000 08:12 6818382                    /usr/bin/cat
555f84e0a000-555f84e2b000 rw-p 00000000 00:00 0                          [heap]
7f207aec6000-7f207b1b0000 r--p 00000000 08:12 6833710                    /usr/lib/locale/locale-archive
7f207b1b0000-7f207b1b3000 rw-p 00000000 00:00 0 
7f207b1b3000-7f207b1df000 r--p 00000000 08:12 6819206                    /usr/lib/libc.so.6
7f207b1df000-7f207b355000 r-xp 0002c000 08:12 6819206                    /usr/lib/libc.so.6
7f207b355000-7f207b3a9000 r--p 001a2000 08:12 6819206                    /usr/lib/libc.so.6
7f207b3a9000-7f207b3aa000 ---p 001f6000 08:12 6819206                    /usr/lib/libc.so.6
7f207b3aa000-7f207b3ad000 r--p 001f6000 08:12 6819206                    /usr/lib/libc.so.6
7f207b3ad000-7f207b3b0000 rw-p 001f9000 08:12 6819206                    /usr/lib/libc.so.6
7f207b3b0000-7f207b3bf000 rw-p 00000000 00:00 0 
7f207b3c1000-7f207b3e3000 rw-p 00000000 00:00 0 
7f207b3e3000-7f207b3e5000 r--p 00000000 08:12 6819194                    /usr/lib/ld-linux-x86-64.so.2
7f207b3e5000-7f207b40c000 r-xp 00002000 08:12 6819194                    /usr/lib/ld-linux-x86-64.so.2
7f207b40c000-7f207b417000 r--p 00029000 08:12 6819194                    /usr/lib/ld-linux-x86-64.so.2
7f207b418000-7f207b41a000 r--p 00034000 08:12 6819194                    /usr/lib/ld-linux-x86-64.so.2
7f207b41a000-7f207b41c000 rw-p 00036000 08:12 6819194                    /usr/lib/ld-linux-x86-64.so.2
7ffe0d2a4000-7ffe0d2c5000 rw-p 00000000 00:00 0                          [stack]
7ffe0d369000-7ffe0d36d000 r--p 00000000 00:00 0                          [vvar]
7ffe0d36d000-7ffe0d36f000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]

[hbx360]

D'accord merci pour vos explications.

@WhiteCrow aurais-tu éventuellement un lien pour des cours sur les emplacements mémoires que tu cite dans ton dernier message ?

Sinon je regarderai sur internet.

[WhiteCrow]

Ce ne sont pas des choses que l'on retrouve dans des cours, du moins pas à ma connaissance. Ce sont des infos que tu retrouves dans des articles, des descriptions et manuels techniques, etc. Les mots clés sont C memory model, et ce que j'ai décrit convient surtout pour des architectures usuelles ; tu auras aussi des infos dans les manuels de gcc et clang, voire des linkers comme ld ou gold …

[hbx360]

Merci pour ta réponse.