Question sur free

bonjour à tous,
J'ai une question de curiosité qui me tarrabuste depuis un moment.
quand on fait

Code:

---

1 2 3

void* ptr= malloc(taille); .... free(ptr);

---

la taille exact est d'abord reservé puis apres liberé.
bon jusque là ca roule. ;-)

mais puisque ptr ne contient qu'une adresse comment le runtime sait il la taille à liberer ?

Je sais je me pose des fois des questions méta physique mais j'aime bien comprendre à fond les choses. En prime je me dis qu'avec ca je pourrais savoir la taille d'un tableau par exemple.

Citation:

---

Envoyé par zolive

mais puisque ptr ne contient qu'une adresse comment le runtime sait il la taille à liberer ?

Je sais je me pose des fois des questions méta physique mais j'aime bien comprendre à fond les choses. En prime je me dis qu'avec ca je pourrais savoir la taille d'un tableau par exemple.

---

Tu as bien raison de chercher à aller au fond des choses.

Le gestionnaire de mémoire tient une table des blocs de mémoire qu'il alloue et, donc, y associe toutes les infos dont il a besoin. Il me semble même qu'à l'époque du DOS, ces infos tenaient dans une structure de 16 octets qui se trouvait juste avant le début de la mémoire libre réperée par le pointeur. C'était facile de retrouver le tout. :-)


UPDATE ! je refais une précision déjà apportée dans un autre fil : lorsque l'on réserve de la mémoire, celle-ci ne rentre pas dans un état particulier elle-même. C'est juste le système qui marque l'espace en question comme étant réservé et, donc, évite de l'employer à d'autres fins. Sitôt que cette entrée est supprimée, la plage en question est - implicitement - considérée comme libre.

Citation:

---

Envoyé par Obsidian

Tu as bien raison de chercher à aller au fond des choses.

---

Attention quand meme. Pour l'utilisateur, le gestionnaire d'allocation est une boite noire. Il est hors de question d'utiliser des techniques speciales pour par exemple recuperer la taille d'un bloc alloue en allant farfouiller dans la memoire.

Citation:

---

Envoyé par zolive

...
Je sais je me pose des fois des questions méta physique mais j'aime bien comprendre à fond les choses. En prime je me dis qu'avec ca je pourrais savoir la taille d'un tableau par exemple.

---

malloc et free ne proposent qu'une interface. Suivant l'algorithme d'allocation mémoire choisi, le gestionnaire mémoire pourra stocker la taille de façon implicite ou pas....

Dans tous les cas, ce choix d'implémentation devra rester "opaque" pour les routines qui l'utilisent. Sinon on va créer une dépendance entre l'implémentation et l'utilisation qui va pénaliser la portabilité et les évolutions de l'applications.

Exemple: Pour allouer des objets de petite taille (<16 bytes par exemple), malloc pourra retourner un bout au plus juste (et mémoriser sa taille) ou un chunck de 16 bytes.

Si vous voulez ajoutez la fonctionnalité get_memsize comme "retourne moi la taille du block alloué", il serait préférable de créer vos propres malloc et free qui s'appuie sur les "originaux" mais qui implémentent la glue nécessaire pour
que get_memsize fonctionne dans tous les cas.

-W

Citation:

---

Envoyé par zolive

mais puisque ptr ne contient qu'une adresse comment le runtime sait il la taille à liberer ?

---

Il le fait selon des méthode connues de lui seul et qui ne sont pas portables. Le programmeur n'a pas à s'en préoccuper ...

Citation:

---

En prime je me dis qu'avec ca je pourrais savoir la taille d'un tableau par exemple..

---

... par contre il est de son ressort de gérer la taille dans le programme. Une structure comme ceci peut aider :

Code:

---

1 2 3 4 5

struct array_dyn { size_t nb_elem; T *array; };

---

Citation:

---

Envoyé par Obsidian

Il me semble même qu'à l'époque du DOS, ces infos tenaient dans une structure de 16 octets qui se trouvait juste avant le début de la mémoire libre réperée par le pointeur. C'était facile de retrouver le tout. :-)

---

Yes sir !!

Mais cela ne dépendait-il pas de la bibliothèque runtime C utilisée ?
Et donc, de l'environnement de développement (ou du SDK) employé ?

Citation:

---

Envoyé par Médinoc

Mais cela ne dépendait-il pas de la bibliothèque runtime C utilisée ?
Et donc, de l'environnement de développement (ou du SDK) employé ?

---

Si tu parles du DOS, oui et non : c'était dans les spécifications de l'interruption qui servait à ça (21h 48xxh ?). Maintenant, il n'est pas du tout certain que malloc() utilisât cette fonction en particulier.

Quel dommage que cette valeur ne soit pas exploitable par le programmeur alors qu'elle est obligatoire pour la libération de mémoire ! Cela changerai la vie des pauvres programmeurs C !

Citation:

---

Envoyé par TheDrev

Quel dommage que cette valeur ne soit pas exploitable par le programmeur alors qu'elle est obligatoire pour la libération de mémoire ! Cela changerai la vie des pauvres programmeurs C !

---

Sous linux :

Code:

---

size_t malloc_usable_size(void *ptr);

---

(il me semble qu'elle est aussi dispo sous freebsd)
et sous Windows :

Code:

---

size_t _msize(void *memblock);

---

Certes ce n'est pas portable mais ça peut toujours servir!

Citation:

---

Envoyé par nicolas.sitbon

Sous linux :

Code:

---

size_t malloc_usable_size(void *ptr);

---

(il me semble qu'elle est aussi dispo sous freebsd)
et sous Windows :

Code:

---

size_t _msize(void *memblock);

---

Certes ce n'est pas portable mais ça peut toujours servir!

---

A affiner :

Code:

---

1 2 3 4 5 6 7 8 9 10

#if defined(WIN32) || defined (_WIN32) #include <malloc.h> #define mem_dyn_size(p) _msize (p) #elif defined(linux) #include <stdlib.h> #define mem_dyn_size(p) malloc_usable_size (p) #else #error not defined for this platform. You're owned ! #endif

---

Citation:

---

Envoyé par Emmanuel Delahaye

A affiner :

Code:

---

1 2 3 4 5 6 7 8 9 10

#if defined(WIN32) || defined (_WIN32) #include <malloc.h> #define mem_dyn_size(p) _msize (p) #elif defined(linux) #include <stdlib.h> #define mem_dyn_size(p) malloc_usable_size (p) #else #error not defined for this platform. You're owned ! #endif

---

---

Code:

---

1 2 3 4 5 6 7 8

#if defined(WIN32) || defined (_WIN32) #define mem_dyn_size(p) _msize (p) #elif defined(linux) #define mem_dyn_size(p) malloc_usable_size (p) #else #error not defined for this platform. You're owned ! #endif #include <malloc.h>

---

Citation:

---

Envoyé par nicolas.sitbon

Code:

---

1 2 3 4 5 6 7 8

#if defined(WIN32) || defined (_WIN32) #define mem_dyn_size(p) _msize (p) #elif defined(linux) #define mem_dyn_size(p) malloc_usable_size (p) #else #error not defined for this platform. You're owned ! #endif #include <malloc.h>

---

---

on ne peut pas faire ça, car <malloc.h> n'est pas portable. Il faut le mettre dans chaque branche.

Mais d'après le man de FreeBSD, malloc_usable_size() est déclaré dans <stdlib.h> et non <malloc.h>

Citation:

---

Envoyé par Emmanuel Delahaye

on ne peut pas faire ça, car <malloc.h> n'est pas portable. Il faut le mettre dans chaque branche.

Mais d'après le man de FreeBSD, malloc_usable_size() est déclaré dans <stdlib.h> et non <malloc.h>

---

le man FreeBSD se plante (au moins sous linux) autrement ça reste portable puisque dans le pire des cas, le #error arrêtera la compilation.

Citation:

---

Envoyé par nicolas.sitbon

le man FreeBSD se plante (au moins sous linux) autrement ça reste portable puisque dans le pire des cas, le #error arrêtera la compilation.

---

Mouais, j'aime pas trop ce genre de bricolage. A partir du moment où il y a des branches, on ne peut plus factoriser...

Citation:

---

Envoyé par Emmanuel Delahaye

Mouais, j'aime pas trop ce genre de bricolage. A partir du moment où il y a des branches, on ne peut plus factoriser...

---

Je suis d'accord : le but de mon code était simplement de dire que sous Linux, le fichier d'entête est aussi malloc.h.