Discussion :

[zolive]

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

Code :

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

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.

[Obsidian]

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.

[DaZumba]

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.

[wiztricks]

...
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

[Emmanuel Delahaye]

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 ...

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 :

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

1
2
3
4
5
struct array_dyn
{
   size_t nb_elem;
   T *array;
};

[ram-0000]

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 !!

[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é ?

[Obsidian]

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.

[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 !

[nicolas.sitbon]

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 :

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

size_t  malloc_usable_size(void *ptr);

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

Code :

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

size_t _msize(void *memblock);

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

[Emmanuel Delahaye]

Sous linux :

Code :

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

size_t  malloc_usable_size(void *ptr);

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

Code :

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

size_t _msize(void *memblock);

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

A affiner :

Code :

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

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

[nicolas.sitbon]

A affiner :

Code :

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

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 :

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

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>

[Emmanuel Delahaye]

Code :

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

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>

[nicolas.sitbon]

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.

[Emmanuel Delahaye]

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...

[nicolas.sitbon]

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.