Discussion :

[uknow]

Bonsoir,

Ma question concerne la fonction malloc() en C et spécialement le type void* qu'elle retourne. J'ai appris par ailleurs qu'il n'était pas nécessaire de faire un cast du pointeur retourné. Est-ce vrai ? Si c'est le cas merci de m'indiquer la source.

Merci par avance.

[alexrtz]

J'ai appris par ailleurs qu'il n'était pas nécessaire de faire un cast du pointeur retourné. Est-ce vrai ? Si c'est le cas merci de m'indiquer la source.

C'est vrai, mais je trouve la réponse de la FAQ de dvp un poil trop catégorique.
Perso je préfère cette réponse.

[Melem]

Moi j'adhère par contre entièrement la réponse de la FAQ dvp.

1. De l'inutilité : Les raisons les plus fréquentes qui poussent certains programmeurs à caster malloc sont :

a. L'ignorance : "Je mets un cast comme ça c'est sûr que ça marche. Je m'en fiche que ça soit utile ou pas.".

-> Jusqu'à quand programmer dans ces conditions ? Lorsqu'on sait que c'est inutile, il n'y a aucune raison soutenable de le mettre. C'est comme écrire :

Code :

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

long n = (long)1;

Bien sûr que ça marche. Mais le cast est inutile, donc à supprimer.

b. La "C/C++"-mania : "En C++, le cast est requis donc vaut mieux toujours le mettre, même en C où ce n'est pas requis".

-> Il y a peu (pour ne pas dire pas) d'intérêt à écrire du code compatible C et C++. Du code C, même 100% incompatible C++, peut toujours être compilé en C (bien sûr) ensuite utilisé dans du code C++. Pas besoin de programmer en langage spaghetti pour mixer ces deux langages.

2. Du danger :

Le cast force le compilateur à faire la conversion même lorsque le type retourné par malloc n'est pas void *. Si on a oublié d'inclure stdlib.h par exemple, le compilateur supposera que malloc est une fonction qui retourne un int. A cause du cast, le compilateur ne génèrera pas un avertissement du type "int converti en pointeur" or affecter le retour d'une fonction qui renvoie int à un pointeur est dangereux (imagine par exemple que la taille d'un int est différente de celle d'un pointeur, qu'est-ce qui va se passer !? or ce n'est pas que ça ...).

Donc personnellement, je recommande vivement de ne jamais caster malloc lorsqu'on programme en C.

[Pouet_forever]

La plupart du temps les gens font des casts sur malloc parce qu'ils compilent en C++.
Si ce n'est pas ça c'est parce qu'on leur à enseigné comme ça.

[Melem]

Ce qui rejoint ce que j'ai dit. Selon toi :

- Soit ils font volontairement du C/C++ (ce qui peut faire l'objet d'un débat : "Faire du C/C++ : est-ce bien ou mal ?"), ce qui rejoint mon 1.b.

- Soit ils le font sans le savoir mais juste parce qu'on le leur a enseigné ainsi, ce qui rejoint mon 1.a. et dans ce cas, soit le prof lui-même ne connaît pas assez le C (croyez-moi, ça existe, j'ai vu de mes propres yeux et pas qu'une seule fois), soit c'est un prof qui n'a pas l'intention de tout enseigner à ses élèves (et ça aussi, ça existe).

[alexrtz]

Les raisons les plus fréquentes qui poussent certains programmeurs à caster malloc sont :

a. L'ignorance : "Je mets un cast comme ça c'est sûr que ça marche. Je m'en fiche que ça soit utile ou pas.".

(...)

b. La "C/C++"-mania : "En C++, le cast est requis donc vaut mieux toujours le mettre, même en C où ce n'est pas requis".

Perso c'est plutôt pour cette raison :

On the other hand, some programmers prefer to make every conversion explicit, to record that they have considered each case and decided exactly what should happen

Et comme je compile avec des options qui me si y a le moindre warning, je risque pas d'oublier un en-tête

[souviron34]

Moi j'adhère par contre entièrement la réponse de la FAQ dvp.
..
Donc personnellement, je recommande vivement de ne jamais caster malloc lorsqu'on programme en C.

Et personellement, et j'ai déjà eu l'occasion de le dire plusieurs fois, je suis contre cette "recommandation", pour 2 raisons..

• a) l'argument du "danger" :
  
  ce danger n'existe que pour des programmeurs débutants. Il faudrait alors interdire toute utilisation "limite" de tout ce qui en C peut être mal interpété ou mal utilisé par un débutant.. ça fait beaucoup..
  
  
  
• b) l'aspect documentaire / maintenance :
  
  le fait d'avoir des casts explicites dans le code non seulement permet à tout moment de la lecture de savoir à quel type on a affaire, mais également, en cas de modification du type d'un champ, de relever instantanément (erreur ou warning de compil) toute inconsistance entre pointeurs..

Alors je suis effectivement beaucoup plus d'accord avec ce que dit comp.lang.c qu'avec une politique et une affirmation péremptoire de la "nocivité" de cette utilisation...

[fearyourself]

Tout ceci est un troll énorme entre deux factions de la programmation C. Les gens pour le cast auront leurs raisons et les gens contre aussi.

Je suis contre le cast puisque je compile avec des options de compilation strictes et parce que j'ai déjà eu un problème dû à ce cast.

Jc

[souviron34]

pour le troll, effectivement il semble assez velu..

Néanmoins, je ne vois pas ce que viennent faire des options strictes dans ce débat..

Je compile aussi avec des options strictes

[Mac LAK]

Sujet récurrent en effet... Juste une réaction sur un point :

-> Il y a peu (pour ne pas dire pas) d'intérêt à écrire du code compatible C et C++. Du code C, même 100% incompatible C++, peut toujours être compilé en C (bien sûr) ensuite utilisé dans du code C++. Pas besoin de programmer en langage spaghetti pour mixer ces deux langages.

Il y en a pourtant, notamment sur les modules d'interfaces inter machines (ex : définition de structures, protocoles de communication, etc.).

En effet, avoir du code compilant indifféremment en C et en C++ permet les points suivants :

1. Même fichier source pour toutes les cibles, donc risques de régressions très fortement réduit lors des évolutions.
   Pour être honnête, on peut aussi bien sûr avoir ceci avec un mix C/C++, mais dans ce cas on n'a pas le point 2.
2. Sur les cibles compilées en C++, évite d'avoir à utiliser un deuxième compilateur et/ou de la compilation conditionnelle à base de extern "C", qui pose parfois des soucis lors de l'édition de liens. Ou tout simplement parce qu'il faut "répéter" les réglages du compilateur C++ vers les réglages du compilateur C, ce qui est là encore une source de régressions.
3. Permet de supporter les compilateurs C non ANSI qui existent sur certaines cibles, notamment les microcontrôleurs... En effet, certains de ces compilateurs ont un prototype pour malloc qui renvoie autre chose qu'un void*.
   Oui, ces compilateurs sont moches, vilains et tout ce que l'on veut, j'approuve des deux mains. Mais quand on n'a pas le choix parce que c'est le seul et unique compilateur existant pour cette cible, et que ladite cible est imposée par le client ou par l'historique, et bien il faut faire avec.

Toutefois, en dehors de modules destinés et dédiés à la communication entre machines de nature assez différente (au niveau architecture, endianness, compilateurs et normes supportées), il est effectivement assez rare d'avoir l'utilité réelle de compiler en mode compatible C et C++. Mais le cas de figure existe, et ne doit pas être omis.

[Melem]

En effet, avoir du code compilant indifféremment en C et en C++ permet les points suivants :

1. Même fichier source pour toutes les cibles, donc risques de régressions très fortement réduit lors des évolutions.
Pour être honnête, on peut aussi bien sûr avoir ceci avec un mix C/C++, mais dans ce cas on n'a pas le point 2.
2. Sur les cibles compilées en C++, évite d'avoir à utiliser un deuxième compilateur et/ou de la compilation conditionnelle à base de extern "C", qui pose parfois des soucis lors de l'édition de liens. Ou tout simplement parce qu'il faut "répéter" les réglages du compilateur C++ vers les réglages du compilateur C, ce qui est là encore une source de régressions.

Ca ne ressemble pas un peu à :

En effet, avoir du code compilant indifféremment en C et en C++ permet les points suivants :

1. avoir du code compilant indifféremment en C et en C++, donc ...

2. avoir du code compilant indifféremment en C et en C++, ...

?

Bref, c'est justement ce qui n'a pas d'intérêt, selon moi. La compatibilité au niveau binaire est, de loin, plus importante et plus avantageuse que la compatibilité au niveau "source". On a des centaines de langages qui n'ont strictement rien à voir alors qu'on a toujours réussi à les rendre binaire-compatibles. Et puis, faire du C avec le C++ ... ça ne me dit pas grand-chose.

Pour le 3, ça peut passer mais là c'est maintenant un problème purement C. Ca ça peut être une raison de caster malloc.

Bref, avant de continuer le débat, je tiens à vous informer que la FAQ en question a été mise à jour (merci à Pouet_Forever) et cela datant du 30/12/2009 je crois. Je rappelle le lien : [FAQ] Faut-il caster malloc ?. C'est un bon compromis non (avec la même conclusion quand même ).

[Mac LAK]

Ca ne ressemble pas un peu à :<snip>

Non. Le premier est, bien entendu, faisable par plusieurs méthodes, dont la tienne et la mienne.
La seconde, par contre, impose de régler (makefile, projet, machintruc) DEUX compilateurs au lieu d'un seul, avec des options par forcément simples à mettre en concordance... Sans parler du fait de peut-être devoir déployer un compilateur de plus.

La compatibilité binaire est bien sûr très importante, mais une compatibilité au niveau source offre parfois de bien meilleurs avantages.

C'est un bon compromis non (avec la même conclusion quand même ).

Cela a au moins le mérite d'être très nettement moins dogmatique que la version précédente... Je mentionnerais juste que les compilateurs non-ANSI ne sont pas forcément aussi vieux que ça !

[souviron34]

Bref, avant de continuer le débat, je tiens à vous informer que la FAQ en question a été mise à jour (merci à Pouet_Forever) et cela datant du 30/12/2009 je crois. Je rappelle le lien : [FAQ] Faut-il caster malloc ?. C'est un bon compromis non (avec la même conclusion quand même ).

ça s'améliore, mais ce n'est pas encore ça..

Quand je lis :

dans lequel caster malloc est non seulement inutile mais aussi de mauvais style).

Je suis absolument désolé mais je suis résolument contre ces épithètes..

Si on veut être une vraie FAQ, on devrait dire comme le dit comp.lang.c..

"Il y a 2 styles. Chacun a ses pour et ses contres. Mais peu importe celui que vous prenez, votre style doit être homogène"



PS: et à la limite, lister les aguments en faveur des 2 approches..

MAis je ne vois pas ce qui vous permet de juger que c'est "un mauvais style"..