Re: [gull] Subtilité de C n° 2 : type de retour de malloc

[Marc Mongenet]

Je me réponds à moi-même pour complèter mon message
initial et clore cette subtilité n°2.
NB : J'utilise gcc-3.3, car gcc 4 a une extension non standard
qui reconnait malloc comme une fonction builtin, et donne des
messages d'erreurs particuliers.


Fichier f1.c (buggué !) :
------
void f() { int *p = malloc(sizeof(int)); }
------
marc> gcc-3.3 -c f1.c
f1.c: Dans la fonction « f »:
f1.c:1: attention : initialisation transforme un entier en pointeur
sans transtypage
marc>

L'avertissement nous rattrape à la onzième heure.
L'origine du problème est qu'on a oublié le #include<stdlib.h>.
L'exécutable va probablement crasher sur architecture 64 bits.


Fichier f2.c (buggué !) :
------
void f() { int *p = (int*)malloc(sizeof(int)); }
------
marc> gcc-3.3 -c f2.c
marc>

Aucun avertissement ! C'est le danger de la méthode du cast
explicite. Pourtant l'exécutable va probablement crasher sur
architecture 64 bits, exactement pour la même raison que f1.c.


Fichier f3.c (buggué !) :
------
void f() { int *p = (int*)malloc(sizeof *p); }
------
marc> gcc-3.3 -c f3.c
marc>

Aucun avertissement ! C'est le danger de la méthode du cast
explicite. Pourtant l'exécutable va probablement crasher sur
architecture 64 bits, exactement pour la même raison que f1.c.


Fichier f4.c (buggué !) :
------
#include <stdlib.h>
void f() { int *p = malloc(sizeof(short)); }
------
marc> gcc-3.3 -c f4.c
marc>

Aucun avertissement ! C'est le danger de la méthode du cast
implicite, car le compilateur ne remarque pas l'incohérence
entre le int*p et le sizeof(short).


Marc Mongenet