{"id":7613,"date":"2026-09-17T22:40:00","date_gmt":"2026-09-17T20:40:00","guid":{"rendered":"https:\/\/sbi29.fr\/blog\/securite-et-resilience-des-reseaux\/comprendre-le-cast-en-c-conversion-explicite-et-implicite-expliquees\/"},"modified":"2026-09-17T22:40:00","modified_gmt":"2026-09-17T20:40:00","slug":"comprendre-le-cast-en-c-conversion-explicite-et-implicite-expliquees","status":"publish","type":"post","link":"https:\/\/sbi29.fr\/blog\/securite-et-resilience-des-reseaux\/comprendre-le-cast-en-c-conversion-explicite-et-implicite-expliquees\/","title":{"rendered":"Comprendre le cast en C : conversion explicite et implicite expliqu\u00e9es"},"content":{"rendered":"

Le cast en C : conversion explicite et conversion implicite<\/h1>\n
\n

\nEn C, une valeur change de type bien plus souvent que le programmeur ne l’\u00e9crit<\/strong>. Le compilateur convertit tout seul dans une addition, dans un appel de fonction, dans une affectation ; le cast<\/strong> ne fait qu’ajouter une conversion explicite, demand\u00e9e \u00e0 la main. Comprendre le cast en C<\/strong>, c’est donc surtout savoir quelles conversions se produisent sans qu’on les demande, et lesquelles la norme d\u00e9finit vraiment.\n<\/p>\n

\n
R\u00e9ponse directe<\/div>\n
Un cast<\/strong> s’\u00e9crit (type) expression<\/code> et force une conversion. Une conversion implicite<\/strong> est appliqu\u00e9e par le compilateur selon le contexte (promotions enti\u00e8res, conversions arithm\u00e9tiques usuelles, affectation, passage d’argument). Les deux suivent les m\u00eames r\u00e8gles de conversion<\/strong> : le cast ne cr\u00e9e pas un m\u00e9canisme \u00e0 part, il d\u00e9clenche explicitement celui qui existe d\u00e9j\u00e0.<\/div>\n<\/div>\n

Les fondamentaux : (type) expression et conversions implicites<\/h2>\n

\nLa syntaxe canonique du cast est (type) expression<\/code>. Elle ne modifie pas l’objet d’origine : elle produit une nouvelle valeur<\/em> du type demand\u00e9. Tout le reste du sujet tient dans deux familles de conversions implicites que la norme d\u00e9crit pr\u00e9cis\u00e9ment.\n<\/p>\n

\nLes promotions enti\u00e8res<\/strong> s’appliquent d’abord aux types de rang inf\u00e9rieur ou \u00e9gal \u00e0 int<\/code>. La norme ISO C les formule ainsi : \u00ab If an int can represent all values of the original type, the value is converted to an int; otherwise, it is converted to an unsigned int. These are called the integer promotions.<\/em> \u00bb Elle ajoute que \u00ab the integer promotions preserve value including sign<\/em> \u00bb. Autrement dit, un char<\/code> ou un short<\/code> ne participe jamais directement \u00e0 un calcul : il est d’abord promu.\n<\/p>\n

\nViennent ensuite les conversions arithm\u00e9tiques usuelles<\/strong>, qui d\u00e9terminent un type commun aux deux op\u00e9randes d’un op\u00e9rateur arithm\u00e9tique. L’ordre compte : si l’un des op\u00e9randes est un long double<\/code>, on converge vers long double<\/code> ; sinon vers double<\/code> ; sinon vers float<\/code>. Si aucun op\u00e9rande n’est flottant, les promotions enti\u00e8res sont appliqu\u00e9es aux deux op\u00e9randes<\/strong>, puis les r\u00e8gles de type commun entier s’appliquent.\n<\/p>\n

\nC’est ce m\u00e9canisme qui explique le pi\u00e8ge le plus classique du langage, la division enti\u00e8re :\n<\/p>\n

#include <stdio.h>\nint main(void)\n{\n    int a = 7, b = 2;\n    printf(\"a \/ b         = %f\\n\", (double)(a \/ b));\n    printf(\"(double)a \/ b = %f\\n\", (double)a \/ b);\n    return 0;\n}<\/code><\/pre>\n
\n
Sortie<\/div>\n
a \/ b         = 3.000000<\/code>
(double)a \/ b = 3.500000<\/code><\/div>\n<\/div>\n
\nDans le premier cas, a<\/code> et b<\/code> sont deux int<\/code> : la division est enti\u00e8re et le r\u00e9sultat vaut 3 avant<\/em> toute conversion vers double<\/code>. Dans le second, le cast fait de a<\/code> un double<\/code> ; les conversions arithm\u00e9tiques usuelles alignent alors b<\/code> sur double<\/code>, et la division est flottante. Depuis C99, la division enti\u00e8re est tronqu\u00e9e vers z\u00e9ro<\/strong>.\n<\/p>\n
Ce que la norme d\u00e9finit, et ce qu’elle laisse ind\u00e9fini<\/h2>\n
\nC’est ici que la plupart des articles sur le cast induisent en erreur. Trois expressions circulent comme si elles \u00e9taient synonymes \u2014 ind\u00e9fini<\/em>, non sp\u00e9cifi\u00e9<\/em>, d\u00e9fini par l’impl\u00e9mentation<\/em> \u2014 alors qu’elles d\u00e9signent trois r\u00e9gimes distincts. Un comportement d\u00e9fini par l’impl\u00e9mentation<\/strong> est document\u00e9 par le compilateur et reste pr\u00e9visible sur une plateforme donn\u00e9e ; un comportement ind\u00e9fini<\/strong> ne donne aucune garantie et autorise le compilateur \u00e0 optimiser le code comme si le cas ne pouvait pas survenir.\n<\/p>\n\n\n\n\n\n\n\n\n\n
Conversion<\/th>\nR\u00e9gime<\/th>\nCe que dit la source<\/th>\n<\/tr>\n<\/thead>\n
Entier → type non sign\u00e9<\/strong> trop \u00e9troit<\/td>\nD\u00e9fini<\/span><\/td>\nLa valeur est ramen\u00e9e dans l’intervalle du type par ajouts ou soustractions r\u00e9p\u00e9t\u00e9s de 2^N : arithm\u00e9tique modulo.<\/td>\n<\/tr>\n
Entier → type sign\u00e9<\/strong>, valeur non repr\u00e9sentable<\/td>\nD\u00e9fini par l’impl\u00e9mentation<\/span><\/td>\nLe r\u00e9sultat est d\u00e9fini par l’impl\u00e9mentation, qui peut aussi lever un signal.<\/td>\n<\/tr>\n
D\u00e9passement<\/strong> en arithm\u00e9tique sign\u00e9e<\/td>\nInd\u00e9fini<\/span><\/td>\nLe r\u00e9sultat peut boucler, provoquer un pi\u00e8ge, ou \u00eatre supprim\u00e9 par l’optimiseur.<\/td>\n<\/tr>\n
Flottant → entier<\/td>\nTroncature, puis ind\u00e9fini<\/span><\/td>\nLa partie fractionnaire est \u00e9cart\u00e9e (troncature vers z\u00e9ro) ; si la partie enti\u00e8re n’est pas repr\u00e9sentable, le comportement est ind\u00e9fini.<\/td>\n<\/tr>\n
double<\/code> → float<\/code><\/td>\nD\u00e9fini par l’impl\u00e9mentation<\/span><\/td>\nValeur inchang\u00e9e si elle est repr\u00e9sentable exactement ; sinon arrondi \u00e0 la valeur voisine, la direction d’arrondi \u00e9tant d\u00e9finie par l’impl\u00e9mentation.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\nLa distinction la plus utile en pratique est la premi\u00e8re ligne contre la troisi\u00e8me. Convertir<\/strong> un entier n\u00e9gatif vers un type non sign\u00e9 n’a rien d’accidentel : la norme ISO C pr\u00e9voit que \u00ab the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type<\/em> \u00bb. Le r\u00e9sultat est parfaitement d\u00e9termin\u00e9. En revanche, d\u00e9passer la capacit\u00e9 d’un type sign\u00e9 au cours d’un calcul<\/strong> est un comportement ind\u00e9fini \u2014 ce n’est pas la m\u00eame op\u00e9ration, et c’est elle qui casse les programmes.\n<\/p>\n
\nPour la conversion flottant vers entier, la norme est tout aussi nette : \u00ab the fractional part is discarded (i.e., the value is truncated toward zero). If the value of the integral part cannot be represented by the integer type, the behavior is undefined.<\/em> \u00bb La troncature va donc vers z\u00e9ro, et non vers le bas : -3.7<\/code> devient -3<\/code>, pas -4<\/code>.\n<\/p>\n
#include <stdio.h>\nint main(void)\n{\n    unsigned char u = (unsigned char)-1;\n    printf(\"(unsigned char)-1 = %u\\n\", u);\n    printf(\"(int)-3.7 = %d\\n\", (int)-3.7);\n    printf(\"(int)3.7  = %d\\n\", (int)3.7);\n    return 0;\n}<\/code><\/pre>\n
\n
Sortie (octet de 8 bits)<\/div>\n
(unsigned char)-1 = 255<\/code>
(int)-3.7 = -3<\/code>
(int)3.7  = 3<\/code><\/div>\n<\/div>\n
\nLa premi\u00e8re ligne m\u00e9rite une pr\u00e9cision : la valeur obtenue est UCHAR_MAX<\/code>, c’est-\u00e0-dire le modulo d\u00e9crit par la norme. Elle vaut 255 lorsque l’octet fait 8 bits<\/em>, ce qui est le cas courant mais reste une propri\u00e9t\u00e9 de l’impl\u00e9mentation, expos\u00e9e par CHAR_BIT<\/code>.\n<\/p>\n
\n
\n    \u25b6 YouTube<\/span>
\n    LES TEACHERS DU NET<\/span>
\n    11 k vues<\/span><\/div>\n
  
\n    \"LANGAGE
\n    \u25b6<\/span><\/span><\/a><\/p>\n
LANGAGE C – 15 – Le casting ou transtypage<\/div>\n<\/div>\n
Bonnes pratiques : largeurs de types, pointeurs, lisibilit\u00e9<\/h2>\n
\nLa premi\u00e8re r\u00e8gle est de ne jamais \u00e9crire une taille de type en dur<\/strong>. La norme ne fixe pas que int<\/code> occupe quatre octets ni long<\/code> huit : elle impose des largeurs minimales<\/em> et laisse le reste \u00e0 l’impl\u00e9mentation. Les valeurs r\u00e9elles se lisent dans <limits.h><\/code> et se mesurent avec sizeof<\/code> :\n<\/p>\n
#include <stdio.h>\n#include <limits.h>\nint main(void)\n{\n    printf(\"CHAR_BIT    = %d\\n\", CHAR_BIT);\n    printf(\"sizeof(int) = %zu\\n\", sizeof(int));\n    printf(\"INT_MAX     = %d\\n\", INT_MAX);\n    return 0;\n}<\/code><\/pre>\n
\nCe programme n’a pas de sortie universelle<\/strong> : c’est pr\u00e9cis\u00e9ment ce qu’il d\u00e9montre. Un code portable interroge <limits.h><\/code> plut\u00f4t que de supposer une largeur, et raisonne sur INT_MAX<\/code> plut\u00f4t que sur une constante recopi\u00e9e.\n<\/p>\n
\nDeuxi\u00e8me point, souvent mal compris : le cast du retour de malloc<\/code> n’est pas n\u00e9cessaire en C<\/strong>. La fonction renvoie un void *<\/code>, et la norme pr\u00e9voit qu’un pointeur vers void<\/code> \u00ab can be implicitly converted to and from any pointer to object type<\/em> \u00bb. L’\u00e9criture int *tab = malloc(10 * sizeof(int));<\/code> est donc correcte telle quelle. Ajouter (int *)<\/code> ne renforce aucune s\u00e9curit\u00e9 m\u00e9moire ; c’est une habitude venue du C++, o\u00f9 la conversion implicite n’existe pas. Ce qui compte r\u00e9ellement ici, c’est de tester le retour<\/strong>, malloc<\/code> renvoyant un pointeur nul en cas d’\u00e9chec.\n<\/p>\n
\nTroisi\u00e8me point : un cast est une affirmation adress\u00e9e au compilateur<\/strong>. En \u00e9crivant (short)x<\/code>, on lui demande de ne plus signaler une conversion qu’il aurait diagnostiqu\u00e9e. C’est utile quand la r\u00e9duction est voulue et ma\u00eetris\u00e9e ; c’est un moyen commode de faire taire un avertissement l\u00e9gitime dans le cas contraire. D’o\u00f9 trois r\u00e9flexes utiles : compiler avec les avertissements activ\u00e9s, v\u00e9rifier avant le cast que la valeur tient dans le type cible, et commenter tout cast dont la raison n’est pas \u00e9vidente \u00e0 la lecture.\n<\/p>\n
\nEnfin, les conversions entre types de pointeurs rel\u00e8vent d’un r\u00e9gime encore plus strict que les conversions arithm\u00e9tiques. La norme pr\u00e9cise que la conversion d’un pointeur vers un type entier a un r\u00e9sultat d\u00e9fini par l’impl\u00e9mentation, et que le comportement devient ind\u00e9fini si le r\u00e9sultat n’est pas repr\u00e9sentable dans le type entier vis\u00e9. Un cast de pointeur n’est donc jamais anodin.\n<\/p>\n
\u00c0 retenir<\/h2>\n
\n
L’essentiel<\/div>\n