Caster ou pas le retour de malloc

**souviron34** · 07/03/2008, 17h31

et j'ajouterais que, meme si c'est peut-etre inutile, la remarque de Jean-Marc est tout a fait correcte, en particulier pour des gros codes : l'aspect documentaire est important....

M'enfin tout ce debat est apparu purement parce que ca me choquait un peu de voir a chaque fois dit systematiquement "on ne caste pas le retour de malloc"....

Et que l'aspect "dangerosite" est totalement negligeable...

Donc cette position "de principe" m'apparaissait juste comme un tantinet "ayaotellesque"

(et denuee de fondement)

**Médinoc** · 07/03/2008, 17h43

Tu oublies que de toute façon, "On n'utilise pas de cast C-style en C++" non plus.

Donc, caster le retour de malloc() est une mauvaise pratique à la fois en C et en C++.

**Médinoc** · 07/03/2008, 17h49

Entre entiers et flottants, peut-être, mais c'est le static_cast qui est recommandé.
Entre pointeurs, c'est vraiment déconseillé (et de pointeur à flottant, n'en parlons pas...)

**souviron34** · 07/03/2008, 17h53

Envoyé par Médinoc

Tu oublies que de toute façon, "On n'utilise pas de cast C-style en C++" non plus.

Donc, caster le retour de malloc() est une mauvaise pratique à la fois en C et en C++.

je n'oublie pas, je m'en fiche royalement

je suis en C, je programme en C, et je me contrefiche de ce qui se passe en C++...

**corrector** · 07/03/2008, 18h09

Envoyé par Médinoc

Entre entiers et flottants, peut-être, mais c'est le static_cast qui est recommandé.
Entre pointeurs, c'est vraiment déconseillé (et de pointeur à flottant, n'en parlons pas...)

Justement, il n'existe pas de cast de pointeur à flottant, en C ou en C++.

Donc, quand on écrit :

Code :

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

double d = (double) foo();

foo() ne peut pas être de type pointeur, c'est forcément un type numérique.

**Médinoc** · 07/03/2008, 18h12

Tant mieux.

**Vincent Rogier** · 07/03/2008, 19h38

Envoyé par Médinoc

Tu oublies que de toute façon, "On n'utilise pas de cast C-style en C++" non plus.

Juste pour faire l'avocat du diable : Pourtant C++ autorise les "cast C-style"

**Emmanuel Delahaye** · 07/03/2008, 21h19

Envoyé par souviron34

bah plein de cas, dès que tu as par exemple une structure d'un certain type, même en la passant comme pointeur, et que tu passes une structure équivalente, mais d'un autre nom que celui utilisé dans la déclaration du prototype...

Ca dépend de 'équivalente'

Si c'est 'identique', pourquoi 2 noms différents ? Ou alors utiliser un alias (typedef)...
Si c'est 'compatible', ça demande à être vérifié et là, oui, le cast est indispensable.

Ou une variable short que tu veux passer à une fonction attendant un int, etc etc....

Un compilateur bien réglé te jettera si tu ne mets pas de cast...

Dans ce cas précis, non. Le short est promu silencieusement en int et basta.

Et donc, si je suis ce que vous dites, il faut déconseiller l'usage du cast, mais il sera demandé dans certaines conditions

pas évident comme notion quand on débute...

On utilise pas de cast, sauf si c'est requis. C'est tout et c'est simple.

Et quand on ne débute plus, ben l'inconvénient cité n'est plus important, car on sait ce qu'on fait..

Mais pourquoi écrire du code inutile et qui complique la maintenance ? Personnellement, j'ai autre chose à faire... On peut aussi doubler les parenthèses

Code :

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

if ((p != NULL))

... des fois qu'y en ait une qui pète...

Exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
typedef struct pPere {
    int age ;
    int nb_Enfs  ;
    char *Nom ;
} Pere ;
 
typedef struct pFils {
    int age ;
    int nb_Enfs  ;
    char *Nom ;
} Fils ;

Si deux mêmes structures ont des noms différents, il y a un problème d'analyse des données...

Code :

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

1
2
3
4
5
6
7
8
9
10
typedef struct {
    int age ;
    int nb_Enfs  ;
    char *Nom ;
} personne ;
 
<...>
 
personne pere;
personne fils;

rien de sorcier et aucun cast n'est requis.

**Emmanuel Delahaye** · 07/03/2008, 21h24

Envoyé par souviron34

pas dans un passage de fonction, si la déclaration du prototype attend un int...

Ben si...

**Emmanuel Delahaye** · 07/03/2008, 21h27

Envoyé par souviron34

peut-être que cela marche pour short <-> int (je n'en suis pas certain cependant, car je travaille sur des codes où c'est casté et si on enlève le cast le compilo gueule),

Tu es certain que tu compiles en C et non en C++ ?
Tu es certain qu'il s'agit de short et non de short * ?

mais en tous cas avec les exemples donnés plus haut, dès qu'il y a structure ou autre, il faut caster...

Dès qu'il y a un pointeur autre que void*, une vérification est faite par la plupart des compilateurs (mais elle n'est pas exigée par le langage C).

**Emmanuel Delahaye** · 07/03/2008, 21h34

Envoyé par souviron34

que ce soit dans C99, ok.

Mais par exemple dans K&R :

Dans la première édition du K&R, il n'est pas question de void ni de void*. Le type retourné par malloc() était char*, et était donc obligatoire de faire un cast explicite.

Depuis la publication de la norme et la sortie de la 2ème édition, le cast n'est plus obligatoire suite à la création du type void et à la modification du type retour né par malloc() en void*. Malheureusement, certains exemples du K&R 1 sont restés tels quels dans le K&R 2. Les auteurs ont publié un errata :

http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html

Envoyé par errata

142(§6.5, toward the end): The remark about casting the return value of malloc ("the proper method is to declare ... then explicitly coerce") needs to be rewritten. The example is correct and works, but the advice is debatable in the context of the 1988-1989 ANSI/ISO standards. It's not necessary (given that coercion of void * to ALMOSTANYTYPE * is automatic), and possibly harmful if malloc, or a proxy for it, fails to be declared as returning void *. The explicit cast can cover up an unintended error. On the other hand, pre-ANSI, the cast was necessary, and it is in C++ also.

**Emmanuel Delahaye** · 07/03/2008, 21h39

Envoyé par souviron34

mais avec ceci :

En tout cas, pas avec gcc :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
Project   : Forums
Compiler  : GNU GCC Compiler (called directly)
Directory : C:\dev\forums\
--------------------------------------------------------------------------------
Switching to target: default
Compiling: main.c
main.c:1: warning: unused parameter 'param'
Linking console executable: console.exe
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 1 warnings

**Emmanuel Delahaye** · 07/03/2008, 21h44

Envoyé par corrector

Parce que ça aurai fait une différence? Dans quel cas?

Je suppose que le C++ utilisant le principe de la surcharge, le type du paramètre sert à différencier les fonctions... Il n'y a donc pas de promotion comme en C, et si les types de corresponde nt pas, ça doit râler...

Pardon? Un exemple?

Si je reprends l'exemple de Souviron, mais avec des pointeurs :

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
 
void toto (int *param)
{
}
 
void toto1 (void)
{
   short s;
 
   toto (&s);
}
 
int main (void)
{
   toto1 ();
   return 0;
}

Ca donne (gcc):

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
Project   : Forums
Compiler  : GNU GCC Compiler (called directly)
Directory : C:\dev\forums\
--------------------------------------------------------------------------------
Switching to target: default
Compiling: main.c
main.c:1: warning: unused parameter 'param'
main.c: In function `toto1':
main.c:9: warning: passing arg 1 of `toto' from incompatible pointer type
Linking console executable: console.exe
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 2 warnings

ce qui se comprend parfaitement, car c'est une erreur de codage entrainant un comportement indéterminé.

**Emmanuel Delahaye** · 07/03/2008, 21h53

Envoyé par Jean-Marc.Bourguet

Ca reste à justifier. Il y a un effet de documentation pas négligeable.

Je ne vois pas bien en quoi ça aide à la compréhension du code.

Code :

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

T *p = malloc (sizeof *p * n);

est suffisamment clair, non ?

De plus, ça entraine de la maintenance supplémentaire en cas de changement de type, ce qui n'est pas le code que j'ai posté juste au-dessus...

**corrector** · 07/03/2008, 21h56

Envoyé par Emmanuel Delahaye

Je suppose que le C++ utilisant le principe de la surcharge, le type du paramètre sert à différencier les fonctions... Il n'y a donc pas de promotion comme en C, et si les types ne correspondent pas, ça doit râler...

Peut-être pas exactement "comme en C", mais il y a des "integral promotions" et des "integral conversions".

**Emmanuel Delahaye** · 07/03/2008, 22h04

Envoyé par vicenzo

* l'argument "dangeureux" en cas d'oubli d'inclusion de sdtlib.h n'est pas valable. Un compilo bien réglé ne peux laisser passer ca.

J'ai du mal à imaginer qu'un développeur sérieux puisse livrer ou mettre en prod des applis compilées avec un compilo si mal réglé.

Pendant mes 17 ans de programmation dans l'industrie, j'en ai vu des vertes et des pas mures...

Dans les PME que j'ai connu, c'est la jungle totale, tout le monde se mêle de tout, fait n'importe quoi et se bombarde programmeur du jour au lendemain.

Des appels dans fonctions sans prototypes, invisibles par ce qu'on avait désactivé les options de compilations, ça fait partie des choses que j'ai pu constaté...

Activation des warnings : 5000 warnings !

Ensuite, on passe des heures à créer des headers, à corriger des appels de fonctions erronés (erreur de type, manque un paramètre etc.) ... Il ne fat faire aucune hypothèse simplificatrice. En gros, (théorie du chaos), tout ce qui peut arriver finit un jour par arriver. L'oubli de <stdlib.h> en fait partie.

J'ose espérer que les services de développement logiciels des grosses boites sont mieux organisés (ce que j'ai vu à la SAT, par exemple était correct).

**souviron34** · 07/03/2008, 22h12

Envoyé par Emmanuel Delahaye

Tu es certain qu'il s'agit de short et non de short * ?

Envoyé par Emmanuel Delahaye

Si je reprend l'exemple de Souviron, mais avec des pointeurs :

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
 
void toto (int *param)
{
}
 
void toto1 (void)
{
   short s;
 
   toto (&s);
}
 
int main (void)
{
   toto1 ();
   return 0;
}

Ca donne (gcc):

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
Project   : Forums
Compiler  : GNU GCC Compiler (called directly)
Directory : C:\dev\forums\
--------------------------------------------------------------------------------
Switching to target: default
Compiling: main.c
main.c:1: warning: unused parameter 'param'
main.c: In function `toto1':
main.c:9: warning: passing arg 1 of `toto' from incompatible pointer type
Linking console executable: console.exe
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 2 warnings

ce qui se comprend parfaitement, car c'est une erreur de codage entrainant un comportement indéterminé.

oui c'est ce que je voulais dire...

Mais c'est pour ca que je maintient que, comme la notion de cast est cependant indispensable a connaitre, et que il y a peu de code comme tu l'ecris :

Code :

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

1
2
 
T *p = malloc (sizeof *p * n);

et que la plupart du temps (95% mini) c'est plutot :

Code :

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

1
2
 
p = malloc (sizeof *p * n);

il peut etre judicieux d'ecrire pour memoire :

Code :

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

1
2
 
p = (T *) malloc (sizeof *p * n);

pour se rememorer (surtout avec un nom de variable aussi explicite

) que c'est bien du type T*.

Miantenant, comme je le disais au debut, je m'en fiche un peu, mais c'est juste que je ne vois pas le point de le deconseiller aussi fort que cela l'est ici regulierement...

Et que, comme dit ci-dessus et comme le disent Jean-Marc et corrector, cela peut avoir un effet documentaire....

Et que les arguments de "dangerosite" sont absurdes pour tout projet normalement geres en C (j'en ai encore parle autour de moi aujourdhui, et tous les gens ayant de la bouteille en C ont tous travaille avec des "commonC.h" contenant la plupart des entetes standards, que ce soit dans l'aviation, l'embarque, la simulation, ou la reconnaissance de la parole. Je l'avais aussi en meteo, et en medical, et en systemes experts)

Note: je viens de voir que tu parles de PME.. De ce cote-la je ne connais pas, mais dans l'industrie lourde, je n'ai jamais vu ca...

**Emmanuel Delahaye** · 07/03/2008, 22h17

Envoyé par souviron34

Note: je viens de voir que tu parles de PME.. De ce cote-la je ne connais pas, mais dans l'industrie lourde, je n'ai jamais vu ca...

Et je crois que toute la différence est là...

**souviron34** · 07/03/2008, 22h23

Envoyé par Emmanuel Delahaye

Et je crois que toute la différence est là...

sans doute..

Mais a ce compte-la, il faut plutot conseiller de regler correctement son compilo et de se faire justement un "CommonC.h", plutot que de deconseiller l'usage de quelque chose d'inoffensif (puisque ce n'est pas necessaire), voire de benefique en ce qui concerne la lisibilite et maintenance ulterieure..