Version imprimable
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.
C'est dans la FAQ : Faut-il caster malloc ?
C'est vrai, mais je trouve la réponse de la FAQ de dvp un poil trop catégorique.Citation:
Envoyé par uknow
Perso je préfère cette réponse.
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 :
Bien sûr que ça marche. Mais le cast est inutile, donc à supprimer.Code:long n = (long)1;
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.
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.
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).
Perso c'est plutôt pour cette raison :Citation:
Envoyé par Melem
Et comme je compile avec des options qui me :sm: si y a le moindre warning, je risque pas d'oublier un en-tête ;)Citation:
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 personellement, et j'ai déjà eu l'occasion de le dire plusieurs fois, je suis contre cette "recommandation", pour 2 raisons..Citation:
Envoyé par Melem
- 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...
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
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 :P
Oublier d'inclure un fichier d'en-tête n'est pas forcément une erreur de débutant bien que ça arrive le plus souvent, je l'admets, aux débutants. Dans cette réponse, j'ai confondu cstdlib (le stdlib.h de C++) avec cstring (le string.h de C++), d'où inclusion d'un fichier d'en-tête inutile et omission du bon fichier d'en-tête. Je connais au moins 3 raisons (tous des cas déjà vécus, aussi bien quand je débutais que depuis que je me suis amélioré) qui peuvent causer l'oubli d'un fichier d'en-tête :Citation:
a) l'argument du "danger" :
ce danger n'existe que pour des programmeurs débutants.
- Oubli pur et simple. Les oublis, ça peut arriver à tout le monde.
- Confusion avec un autre fichier d'en-tête. On pense avoir inclus le fichier requis mais en fait on a inclus un autre, probablement un qui a un nom ou un rôle plus ou moins ressemblant ...
- Erreur de jugement. Prends ceci par exemple (exemple vraiment très simple) :
Code:
2
3
4
5
6
Ici aussi, dans source1.c, lorsqu'on pense que condition vaut VRAI, alors on pense avoir déjà inclus stdlib.h même s'il n'a pas effectivement été inclus. condition peut être une expression simple, complexe ou hypercomplexe. Faire des erreurs sur l'évaluation de sa valeur peut arriver à tout le monde, pas aux débutants uniquement.Code:
2
On peut tous croire que tu n'as jamais fait d'erreurs de ce genre et que tu n'en feras jamais mais malheureusement, tout le monde n'est pas aussi talentueux que toi. Comme je l'ai dit, toutes ces erreurs me sont déjà arrivées, et j'ai également vu d'autres personnes se faire avoir. C'est un fait, on peut ne pas en discuter.
Explique-moi alors pourquoi personne n'écrit :Citation:
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,
Pour rappeler que y est un long ? Ce n'est pas pour rien que les conversions implicites existent. void * est compatible avec tous les types pointeurs d'objet. Ca ne rime vraiment rien de caster un void *.Code:
2
3
Si tu modifies un type, tu dois déjà modifier pas mal de choses dans le code source lui-même. Ca se limite rarement à ajouter ou modifier des casts ... (un peu (mais pas vraiment) hors-sujet : cf la signature de Médinoc :mouarf:).Citation:
mais également, en cas de modification du type d'un champ, de relever instantanément (erreur ou warning de compil) toute inconsistance entre pointeurs.
Le compilateur aussi ?Citation:
Envoyé par Melem
Parce que si le fichier n'est pas inclus, la déclaration de malloc n'est pas explicite et alors là le compilo gueule (et arrête de compiler si les bonnes options sont settées).
Au risque de radoter avec la FAQ de comp.lang.c :
Caster un pointeur n'est pas une hérésie punissable du fouet, c'est juste un moyen pour les programmeurs qui savent que le cast n'est pas nécessaire mais qui trouvent que c'est plus lisible avec le cast (la notion de lisibilité étant parfois subjective) de clarifier (selon eux) ce qu'ils font.Citation:
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
C'est tout.
Les problèmes cités avec le cast n'existent pas si on regarde les warnings que sort le compilateur (ou qu'on les considère comme des erreurs) et qu'on ne se dit pas bêtement "j'ai eu un exécutable donc y a eu zéro souci à la compilation" (ça c'est clairement une erreur de débutant).
Pas tous. Avec gcc par exemple, l'option -W (enable standard compiler warnings), ni même l'option -pedantic (enable warning demanded by strict ISO C (en mode C90)), ne génère pas le message d'avertissement "implicit declaration". Il faut compiler avec les options les plus strictes possibles (-Wall) pour que ce message soit généré. Et déjà ça ce n'est que gcc, mais on ne va pas passer la soirée à étudier cas par cas les quelques milliers de compilateurs C existants. Je ne connais par contre pas de compilateur qui reste muet devant une conversion implicite d'entier vers pointeur ou de pointeur vers entier même sans options de compilation spéciales, parce que c'est souvent un peu louche.Citation:
Le compilateur aussi ?
Parce que si le fichier n'est pas inclus, la déclaration de malloc n'est pas explicite et alors là le compilo gueule
Au risque de me répéter (3ème fois !), pourquoi on n'écrit jamais long n = (long)1; ?! C'est du même cru que le char * p = (char *)malloc(...);. En quoi expliciter une conversion implicite qui n'a rien de louche améliorerait la lisibilité ? Au contraire, c'est gênant. Bon, je te rejoins quand tu dis que la notion de lisibilité est subjective mais là quand même ...Citation:
Caster un pointeur n'est pas une hérésie punissable du fouet, c'est juste un moyen pour les programmeurs qui savent que le cast n'est pas nécessaire mais qui trouvent que c'est plus lisible avec le cast (la notion de lisibilité étant parfois subjective) de clarifier (selon eux) ce qu'ils font.
On dirait que tu essaies de répondre à ceci :Citation:
Les problèmes cités avec le cast n'existent pas si on regarde les warnings que sort le compilateur (ou qu'on les considère comme des erreurs) et qu'on ne se dit pas bêtement "j'ai eu un exécutable donc y a eu zéro souci à la compilation" (ça c'est clairement une erreur de débutant).
Mais ta phrase est très mal formulée. La mienne aussi apparemment. J'ai répondu, pour contrer souviron34, que lorsqu'on change un type dans un projet, ce n'est rarement en plantant ou en modifiant des casts qu'on va pouvoir mettre à jour le reste du code. Cela demande beaucoup de changements radicaux. Ceci pour conclure que son argument ne peut pas compter.Citation:
Envoyé par Melem
Ceci est mon dernier message sur le sujet, je me suis déjà étendu longuement à ce propos ailleurs sur ce forum...
Voilà ce que c'est de mélanger C et C++ :PCitation:
Envoyé par Melem
Moi je ne fais que du C, et, je ré-itère, je n'ai jamais eu ce cas, en tous cas pas méchamment : à la première compile, le compilo te jette, et si tu fais gaffe à ce qu'il dit, tu t'en rend compte instantanément..
Ce n'est toujours pas une raison valable pour l'instaurer en Commandement...
Une compile, sur un gros projet, tu en fais (en dev, sur ta cope du code) environ une fois toutes les 5 minutes, au plus 1 fois par heure...
Compiler une fois et te rendre compte et corriger, par rapport à perturber des milliers de lignes, franchement pour moi ya pas photo...
Voir plus haut..Citation:
Envoyé par Melem
Un compilo bien réglé et le fait de faire gaffe à la sortie du compilo t'averti dès le premier passage...
Sauf que là c'est une erreur de conception...Citation:
Envoyé par Melem
si le fichier source1 a besoin de stdlib.h, il faut l'inclure de toutes façons, sans intermédiaires.. Sauf (ce que je mentionnais dans un autre thread) sur les gros projets où on a un "CommonC.h" qui comprendra tous les entêtes généraux (stlib, stdio, time, ctype, string, math par exemple)..
Je ne comprend vraiment pas cette façon de NE PAS vouloir inclure plusieurs fois des fichiers d'entête...
Les #ifdef sont justement là pour vérifier qu'on ne les inclue pas inutilement.. Alors pourquoi se priver de mettre les include là où on a besoin ???
Dans un cas comme le cas cité, si je n'ai pas de "CommonC.h", j'incluerais stdlib ET dans include1.h ET dans include.h ET dans source1.c...
J'en ai fait, comme tout le monde, mais comme je l'ai dit l'apparition des erreurs étant tellement évidente à la compile, je ne vois pas en quoi établir une règle aussi absurde et sans fondements réels serait une bonne chose : encore une fois, si on doit faire éviter les erreurs de C possibles, autant enlever les notions de pointeurs, de void, etc etc...Citation:
Envoyé par Melem
Le C est un langage simultanément laxiste et rigoureux, pour des gens qui savent ce qu'ils font..
Comme la langue française peut en même temps être simple et compliquée.. Est-ce pour autant une raison pour écrire en SMS ou ne pas appliquer les règles de grammaire ou d'accord féminin/masculin ???
Parce que là c'est un long, un type élémentaire d'une variable..Citation:
Envoyé par Melem
Soit tu n'as jamais travaillé sur de très gros projets, ou bien tu ne veux pas voir : la plupart du temps, tu as des dizaines de pointeurs, dans des structures, qui peuvent être des élements de listes, de tableaux, des structures, ce que tu veux, qui sont alloués par exemple à un endroit, puis réalloués à d'autres, éventuellement dans diverses fonctions, et libérés encore ailleurs..
La définition de la structure n'est pas forcément proche : que ce soit la routine d'initialisation, d'allocation, de remplissage, de réallocation, de destruction... D'autre part cette structure peut contenir de nombreux pointeurs, chacun pointant sur de nouvelles structures... etc etc..
Avoir tout sans cast explicite fait que tu te tortures l'esprit en relisant le code, savoir que tel sous-sous-sous pointeur sera (est ??) de tel ou tel type...
ça m'arrive en permanence d'avoir des pointeurs de pointeurs de pointeurs de pointeurs... Chacun étant alloué dynamiquement..
Et encore ce n'est qu'un exemple simple...Code:DataSets[k].Source[j].Data[Num].Location[i].Altitude.Value.d
Dans les routines d'allocations ou des réallocation, cela sert d'aspect documentaire... Et cmme je le dit plus bas pour "tracker" un changement..
Absolument.. Void* existe POUR POUVOIR PASSER UN PARAMETRE QUELCONQUE A UNE FONCTION....Citation:
Envoyé par Melem
Son utilisation en tant que cast de résultat de fonction est vraiment d'un usage ultra-limité... :
en fait il n'y a que le malloc, et si on veut stocker un pointeur sur quelque chose d'inconnu dans une structure..
Sauf que justement, sans cast explicite, tu peux oublier tout un tas de trucs, en particulier dans les allocations ou réallocations..Citation:
Envoyé par Melem
Un exemple très simple :
devientCode:char *Table ;
Si d'une part tu n'as pas casté, et d'autre part tu as omis sizeof(char), alors tu es dans une grande panade, sur un très gros soft...Code:char **Table ;
C'est tout...
Comme je n'utlise aucun IDE, que je suis sous Unix/Linux, et que je compile toujours avec gcc en ligne de commande, et j'ai toujours -Wall -strict_prototypes -ansi (-ANSI90)..Citation:
Envoyé par Melem
:P
si tu ne fais pas de conversion EXPLICITE, il suffit d'oublier -Wall et tu ne l'as pas...Citation:
Envoyé par Melem
Les compilateurs ne restent pas muets, encore faut-il voir sortir les erreurs...
C'est tout simplement faux...Citation:
Envoyé par Melem
Reprend mon exemple plus haut..
Un "gros" changement dans un projet n'est pas vraiment pas rapport au type, mais souvent de transfomer une valeur en un tableau, ou un tableau en une liste (et donc un pointeur) ou un tableau à plus de dimensions.
Si on a casté, avec xemacs par exemple (et je suis sûr que c'est pareil avec les IDE classiques) tu fais "replace / toto = (char *) / toto = (char **) /" et il te positionnera sur toutes les lignes contenant ça et te demandera "remplacer ou non ?".. et tu auras beaucoup moins d'occurences (et donc de possibilités de se tromper) que si tu cherches "toto" ou même "toto ="...
J'ai très rarement vu un changement de vrai type, ou alors c'est que la conception avait mal fait son boulot..
Enfin, je ne m'étendrais plus là-dessus, mais je trouve plus qu'irritant la façon de vouloir inculquer comme le Grand Méchant Diable cette pratique..
Et même de la déconseiller..
Je dirais le mieux serait de dire : les 2 options sont possibles et se défendent..
Mais, d'après tes premières remarques, c'est possible que ce soit parce que vous côtoyez trop C++ que vous pensiez ça.... Ou alors c'est peut-être l'usage des IDE, ou du C côté Windows..
Je n'en ai jamais fait, ni des uns ni des autres, et moi, en C pur, je MAINTIENS QU'IL EST BIEN DE CASTER :D
Sujet récurrent en effet... Juste une réaction sur un point :
Il y en a pourtant, notamment sur les modules d'interfaces inter machines (ex : définition de structures, protocoles de communication, etc.).Citation:
Envoyé par Melem
En effet, avoir du code compilant indifféremment en C et en C++ permet les points suivants :
- 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.- 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.
- 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.
Ca ne ressemble pas un peu à :Citation:
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.
? :roll:Citation:
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 :P).
Non. Le premier est, bien entendu, faisable par plusieurs méthodes, dont la tienne et la mienne.Citation:
Envoyé par Melem
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.
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 ! ;)Citation:
Envoyé par Melem
ça s'améliore, mais ce n'est pas encore ça..Citation:
Envoyé par Melem
Quand je lis :
Citation:
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"
:P
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"..
Et si on remplaçait la réponse par ceci alors :J'ai enlevé le "de mauvais style", que je vais la garder pour moi-même, mais il faut quand même préciser que le cast est inutile, sinon ça ne répond pas la question. Que le lecteur décide ensuite de caster ou pas malloc, les int -> long, les type [] -> type *, etc., c'est son affaire, du moment qu'il sait que le cast n'est pas requis en C ANSI.Citation:
soit vous compilez en mode "C++", c'est-à-dire que votre compilateur (qui est donc apparemment capable de compiler aussi bien du code C que du code C++) pense que votre code est écrit en C++ (dans lequel le cast de void * vers un autre type pointeur est obligatoire) et non en C (dans lequel ce cast est inutile). Généralement les fichiers sources C++ portent l'extension .cpp et les fichiers sources C l'extension .c, mais cela peut changer d'un compilateur à un autre. Il faut donc faire bien attention sur ce point là.
ce serait une solution, bien que je n'aime pas le titre du 7.7b, qui est biaisé..Citation:
Envoyé par DaZumba
Ce qu'il dit d'ailleurs dans la dernière ligne..
Je préférerais un titre comme "pourquoi certains trouvent qu'il ne faut pas caster le retour de malloc?"
Je pense que tout ce débat et cette utilisation vient de l'utilisation d'outils comme DEVC++ et autres, qui compilent autant du C que du C++ sans être pour autant généralistes comme gcc.. (d'ailleurs, le fait de faire un point d'entrée commun entre C et C++ est à mon avis délicat, de même que de parler d'un compilateur C++ ou d'extensions cpp)
Un gcc avec les bons flags indiquent de suite qu'on a oublié un fichier d'entête (en particulier stdlib.h, ne serait-ce que pour main)..
Enfin, comme je l'ai dit plus haut, si il fallait enlever tout ce qui peut faire tromper un débutant sous C, il ne resterait plus grand chose.. ([I]pas de **, ni de ***, ni de ++i ou i++, pas de &(tab) ou de (*struct).x ...)
Bon.. désolé de remettre ça sur le tapis, mais j'aurais besoin d'explication concernant les recommandations du CERT.
d'après ce qu'il a été dit sur dans ce topic, le cast d'un malloc est utile pour certains surtout pour rendre le code plus lisible et éviter les erreurs.
Mais je n'ai pas lu (ou alors mal..) le fait qu'avec un void *, si on se trompe de type, le compilateur ne bronchera pas :
source: https://www.securecoding.cert.org/co...allocated+typeCitation:
The argument to malloc() can be any value of (unsigned) type size_t. If the program uses the allocated storage to represent an object (possibly an array) whose size is greater than the requested size, the behavior is undefined. The implicit pointer conversion lets this slip by without complaint from the compiler.
Consider the following example:
An implementation may add padding to a gadget or widget so that sizeof(gadget) equals sizeof(widget), but this is highly unlikely. More likely, sizeof(gadget) is less than sizeof(widget). In that caseCode:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
quietly assigns p to point to storage too small for a widget. The subsequent assignments to p->i and p->d will most likely produce memory overruns.Code:p = malloc(sizeof(gadget)); /* imminent problem */
Casting the result of malloc() to the appropriate pointer type enables the compiler to catch subsequent inadvertent pointer conversions. When allocating individual objects, the "appropriate pointer type" is a pointer to the type argument in the sizeof expression passed to malloc().
In this code example, malloc() allocates space for a gadget and the cast immediately converts the returned pointer to a gadget *:
This lets the compiler detect the invalid assignment because it attempts to convert a gadget * into a widget *.Code:
2
3
4
5
D'une part je te remercie d'avoir fourni un support de qualité à mes recommandations :mrgreen: :Citation:
Envoyé par Trankille
Citation:
Casting the result of malloc() to the appropriate pointer type enables the compiler to catch subsequent inadvertent pointer conversions. When allocating individual objects, the "appropriate pointer type" is a pointer to the type argument in the sizeof expression passed to malloc().
..
This lets the compiler detect the invalid assignment because it attempts to convert a gadget * into a widget *.
Par contre, en ce qui concerne le void*, d'une part le cast est obligatoire, d'autre part bien évidemment il ne peut y avoir de vérification, en tous cas par rapport à la valeur entrée...
Pour la valeur de sortie, il y a automatiquement vérification puisqu'il y a cast obligatoire.
Par contre, s'assurer que le type casté en entrée est le même que celui utilisé en sortie est non seulement impossible , car il faudrait analyser 'ensemble du code et des mouvements de varaibles et suivre les noms des varaibles, mais souvent non souhaitable, car justement souvent un cast en void* permet de faire une fonction "flexible"...
SalutCitation:
Envoyé par Trankille
Tu as trouvé là un SUPERBE exemple donnant au-moins une raison de caster malloc().
Toutefois, et bien que je sois d'accord avec beaucoup d'arguments de souviron34, pour ma part je penche quand-même en faveur définitive du non cast.
Il faut bien comprendre qu'à la base, le C est un langage fait pour ceux qui savent faire et c'est bien précisé que "le programmeur sait ce qu'il fait". Donc le programmeur est sensé, à priori, ne pas se vautrer ; ni en oubliant d'inclure stdlib, ni en confondant le type gadget avec le type widget et donc ces deux arguments, l'un en faveur du "non cast" et l'autre en faveur du cast sont tous deux anihilés par ce prédicat.
Bien sûr il s'agit ici d'un voeu pieu (que celui qui n'est jamais resté scotché 4h sur son code parce qu'il avait écrit "if (pt=NULL)" au lieu de "if (pt == NULL)" me jette la première pierre) mais bon, si le programmeur se vautre, il a autant de chance de se vautrer dans une direction que dans l'autre et là encore les deux arguments s'annulent devant ce fait.
Reste toutefois l'argument ultime => Inutile de caster malloc() parce que justement, le cast d'un void* est inutile. Parce que si on commence à faire de l'inutile, alors il n'y a plus de limite et un jour on verra quelqu'un arriver en disant "il faut vérifier chaque affectation if ((i=5) == 5) parce qu'on n'est pas à l'abri d'une erreur (en fait je voulais mettre 6)" et là, c'est la porte ouverte au grand n'importe quoi.
on va dire que ce n'est pas simplement pour celui qui développe mais surtout pour la maintenance du code et sa relecture pour les (très) gros projets ^^Citation:
Envoyé par Sve@r
merci pour les réponses, ça m'a montré les deux points de vue qui pour moi se valent.
Mais je penche pour le cast quand même notamment pour les programmes "sensibles".
ça n'est pas une question de confondre, mais de pouvoir changer facilement de type tout en ayant une vérification qu'on n'a rien oublié.. :DCitation:
Envoyé par Sve@r
Si tu as mis partout des cast, alors si tu modifies le type "à la main", tu auras instantanément une erreur à la compil... que tu n'auras pas si tu ne l'as pas mis..
Par contre, cet argument tombe si tu utilises un outil (que ce soit via un EDI soit via un sed..)
Mais je maintiens à cause de la lisibilité...
8O tu t'est trompé je suppose....Citation:
Envoyé par Sve@r
Le cast d'un void* est obligatoire... (dans le cas de malloc ça ne l'est pas puisque on ne se sert pas de la structure sauf pour la taille)..
Mais si tu as :
Code:
2
3
pour se servir de data il faudra bien caster à un moment donné... Donc pourquoi utiliser 2 approches différentes ???
malloc est une exception et pas une règle..
En déduire donc une règle est pour le moins osé...
Et à mon avis peu cohérent...
Ce qu'il voulait dire, je suppose, c'est qu'en C, les conversions de void* vers T* et de T* vers void* (pour tout type T) sont implicites. Il n'est donc pas obligatoire de caster explicitement de telles conversions.Citation:
Envoyé par souviron34
Admettons...Citation:
Envoyé par gl
Mais ça ne répond pas à :
Citation:
Envoyé par souviron34
Prenons l'exemple des callbacks que je connais bien...
La callback d'un widget a en paramètre une structure dépendante du widget plus une structure de données client (sous formes de pointeurs).
Cependant, tout widget complexe hérite (au sens réel de classe) de widgets plus simples.
Sa structure dépendante est "recouvrable" en partie par la structure plus simple (via des unions).
Si à l'intérieur de la callback on a besoin d'un paramètre de la structure du widget plus simple, il me semble nettement plus clair à la lecture de mettre :
que de mettre :Code:
2
3
4
5
6
où le lecteur se posera des questions à savoir pourquoi le même pointeur est assigné à 2 structures différentes... Alors qu'avec le cast il sait que on considère le pointeur de 2 manières différentes, comme étant implicitement 2 pointeurs différents.Code:
2
3
4
5
6
Quant aux conversions en sens inverse, si les flags de compil sont mis avec vérification des prototypes et/ou des cast, on se fait jeter proprement si on assigne un pointeur *StructComplexe à un void* sans cast explicite...
Encore un exemple avec les callbacks ci-dessus.. Si on enregistre la fonction Method sans caster avec void* et que le flag -Wstrict_prototypes est mis, on se fera jeter...
Maintenant, c'est effectivement une question de goût, mais en tous cas, ta citation même ("implicite"), ne plaide ni pour une règle, ni pour un comportement à recommander...
Pourtant c'est ce qui est fait lorsqu'on utilise des fonctions style memcpy() ou memset() sans cast explicite des paramètres (et la forme idiomatique semble plutôt être de ne pas caster les paramètres de ces fonctions justement). Et sur les compilateurs que j'utilise, je ne connais pas d'option permettant de lever une erreur ou un warning dans ce cas (et je viens de faire le test avec -Wstrict-prototypes qui ne leve rien dans ce cas).Citation:
Envoyé par souviron34
Sinon, mon propos portait uniquement sur la remarque que j'ai citée. Pas sur la question de fond faut-il ou non caster explicitement void* en C, je n'ai pas (plus) d'avis vraiment tranché à ce sujet. J'aurais plutôt tendance à gérer au cas par cas.
Exact, c'est bien ce que je voulais dire.Citation:
Envoyé par gl
Je sais bien que si j'ai un void *pt et que je veux utiliser *pt, il faudra que j'indique comment je l'utilise donc que je le caste lors de l'utilisation.
Ce que je voulais dire, c'est que je peux copier un void* (donc ce que renvoie malloc) dans n'importe quel <type>* sans avoir besoin de caster.
Sinon bien le coup des callback. Finalement je ne sais plus trop quoi dire donc je vais me ranger de l'avis de gl => voir au cas par cas... :ccool: