Discussion :

[gdpasmini]

Bonjour a tous !

Dans la famille redifinition de fonction je voudrais le realloc !

J'ai fais ce code :

Code :

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

1
2
3
4
5
6
7
8
 
void *Monrealloc(void *ptr, size_t size)
{
     void * monNouveauPointeur = Monmalloc(size);
     memcpy(monNouveauPointeur, ptr, size);
     Monfree(ptr);
     return (void *)monNouveauPointeur;
}

Ca a l'air de marcher mais est ce que le realloc fonctionne comme ceci ?

La raison de cette redeclaration est dû a des pb memoires que j'observe sur un system embarqué. En effet, il arrive parfois que la libération d'un pointeur null fasse planter la machine... Est ce normal ?

[Emmanuel Delahaye]

Ca a l'air de marcher mais est ce que le realloc fonctionne comme ceci ?

Pas tout à fait. Si le pointeur d'initial est NULL, le comportement doit être défini (ce qui n'est pas le cas ici).

Code :

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

1
2
3
4
5
6
 
   if (ptr != NULL)
   {
      memcpy(monNouveauPointeur, ptr, size);
   }
   ...

Note : Le cast à la fin est inutile :

Code :

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

   return monNouveauPointeur;

La raison de cette redeclaration

Tu veux sans doute dire redéfinition...

est dû a des pb memoires que j'observe sur un system embarqué. En effet, il arrive parfois que la libération d'un pointeur null fasse planter la machine... Est ce normal ?

Non. Il doit y avoir un autre problème, genre débordement de bloc alloué ou utilisation de pointeur non initialisé ou NULL...

[Jean-Marc.Bourguet]

Il faut copier une quantité de données correspondant à ce qui était alloué précédemment, pas ce qui est nouvellement alloué.

[Médinoc]

Pour être précis, il faut copier la plus petite des deux tailles (oui, on peut se servir de realloc() pour réduire un espace alloué).

Et aussi, une implication plus profonde de Monrealloc() dans ta gestion du tas pourrait permettre de changer la taille "sur place" s'il n'y a rien qui gène (100% de réussite pour un rétrécissement)...

[gdpasmini]

ok merci beaucoup.. mais pour copier la plus petite des deux tailles, il faut connaitre la taille précédement allouée or lors du realloc on a plus accès a cette information .. Si ?

D'autre part, lors de mes tests, un free fait reellement planter ma machine..
J'ai donc rajouté une protection :

Code :

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

1
2
3
4
5
6
7
8
 
Monfree(void * ptr)
{
  if(ptr == NULL)
    return;
  else
   free(ptr);
}

Depuis, ca plante moin...

[Médinoc]

C'est anormal, il me semble bien que la norme dit que free(NULL) doit "échouer" silencieusement...
(à l'inverse de fclose(NULL) qui est indéfini)

[Emmanuel Delahaye]

ok merci beaucoup.. mais pour copier la plus petite des deux tailles, il faut connaitre la taille précédement allouée or lors du realloc on a plus accès a cette information .. Si ?

Non. D'où problème. A part passer l'info sous la forme d'un paramètre, je ne vois pas d'issue.

D'autre part, lors de mes tests, un free fait reellement planter ma machine..
J'ai donc rajouté une protection :

Code :

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

1
2
3
4
5
6
7
8
 
Monfree(void * ptr)
{
  if(ptr == NULL)
    return;
  else
   free(ptr);
}

Depuis, ca plante moin...

Ca n'a strictement rien résolu du tout.

Déjà cité, mais tellement à-propos :

"Ce n'est pas en cassant le thermomètre qu'on guéri le malade."

[Emmanuel Delahaye]

Il faut copier une quantité de données correspondant à ce qui était alloué précédemment, pas ce qui est nouvellement alloué.

Exact, sinon, on lit dans une zone en partie indéterminée.

Problème, on ne connait pas cette taille, donc on est cuit, on ne peut pas écrire son realloc()...

Affaire réglée.

[Médinoc]

Problème, on ne connait pas cette taille, donc on est cuit, on ne peut pas écrire son realloc()...

Affaire réglée.

Pour être précis, je dirais qu'on ne peut pas écrire de realloc() à un niveau supérieur à celui des malloc() et free() : Le realloc doit au moins être au même niveau, voire à un niveau inférieur.

[gdpasmini]

ola, dsl mai je comprends pas l'histoire des niveaux...

[Jean-Marc.Bourguet]

Problème, on ne connait pas cette taille, donc on est cuit, on ne peut pas écrire son realloc()...

Si on écrit les fonctions malloc, realloc et free, ce qui a l'air d'être le cas de l'OP, on peut stocker cette taille quelque part de sorte qu'on la retrouve après. On en a de toute manière besoin aussi pour le free.

Une technique est de faire précéder les blocs de leur taille.

[Emmanuel Delahaye]

Si on écrit les fonctions malloc, realloc et free, ce qui a l'air d'être le cas de l'OP...

Ca m'a tout l'air d'être de simples wrappers... Pour le reste, OK. attention aux problèmes d'alignement !

[Franck.H]

Pas tout à fait. Si le pointeur d'initial est NULL, le comportement doit être défini (ce qui n'est pas le cas ici).

Code :

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

1
2
3
4
5
6
 
   if (ptr != NULL)
   {
      memcpy(monNouveauPointeur, ptr, size);
   }
   ...

Il me semble que si le pointeur passé en paramètre est NULL, realloc se comporte comme malloc. Cela peut varier d'une implémentation à une autre ?

[Emmanuel Delahaye]

Il me semble que si le pointeur passé en paramètre est NULL, realloc se comporte comme malloc.

Ben oui, d'où la protection de memcpy() par le if ...

Cela peut varier d'une implémentation à une autre ?

Pas si ces implémentations sont conformes au C standard.

[gdpasmini]

on ne peut pas ecrire son propre realloc ?

La protection du memcpy ne le permet il pas ?

[Emmanuel Delahaye]

Il me semble que si le pointeur passé en paramètre est NULL, realloc se comporte comme malloc. Cela peut varier d'une implémentation à une autre ?

Ben oui, d'où la protection de memcpy()...

De toutes façons, comme l'a fait remarqué Jean Marc, on ne peut pas créeer son realloc() [1]. Affaire classée...

-----------------------
[1] à moins de passer un paramètre en plus : 'ancienne_taille'...