Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C cast de pointeur *, ** différence ?

cast de pointeur *, ** différence ?

114 réponses
Avatar
Nico
salut,

j'ai un petit code qui m'étonne... soit une fonction prenant un void*
en paramètre, lors de son appel, si je lui passe un double*, mon
compilateur dit rien... ok.
soit une fonction retournant un void *, lorsque j'assigne un double*
avec le retour de cette fonction, mon compilateur ne dit rien...

ici donc, pas besoin de caster ni le paramètre (en (void*)), ni le
retour de fonction (en (double*))...

maintenant, on prend les même et on recommence, à la différence près
que mon argument n'est plus un void* mais un void**, et mon retour
n'est plus un void* mais aussi un void **. là plus rien ne passe...
lors de l'appel de la fonction je suis obligé de caster mon double** en
void**, et lors du retour, je suis obligé de caster en double**,
pourquoi ?

pour un exemple plus parlant, considérez le code suivant :

void *
vect_new(size_t len, size_t size_type)
{
void *v = malloc(len * size_type);
return v;
}


void
vect_free(void *vect)
{
if(vect) free(vect);
}

/*declaration du vecteur...
pas besoin de faire un cast (double*)*/

double *vect = vect_new(3,sizeof(double));

/*appel sans probleme a la compilation :
pas besoin de faire (void*)vect*/
vect_free(vect);


et maintenant avec des void** :

void **
mat_new(unsigned int nrow, unsigned int ncol, size_t size_type)
{
int i,j;
void **m = malloc(nrow * size_type);
if(m)
{
for(i=0; i<nrow; i++)
{
m[i] = malloc(ncol * size_type);
if(!m[i])
{
for(j=0; j<=i; j++)
free(m[i]);
free(m);
m = NULL;
}
}
}
return m;
}

void
mat_free(void **m,unsigned int nrow)
{
int i;
if(m)
{
for(i=0; i<nrow; i++)
if(m[i])
free(m[i]);
free(m);
}
}

/*declaration de la matrice*/
double **matrice = (double**)mat_new(4,3,sizeof(double));

/*appel sans probleme a la compilation : */
mat_free((void**)matrice,4);

là si je cast pas l'un et l'autre... warning... où se situe la
différence avec le 1er exemple ?

merci de m'éclairer à ce propos.

--
Nico,
http://astrosurf.com/nicoastro
http://nicolas.aunai.free.fr
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
5 6 7 8 9
Avatar
Stephane Legras-Decussy
Gabriel Dos Reis a écrit dans le message :

| C'est possible, mais c'est hors-sujet. Je parle de void* et non de
| void**. Est-ce que la taille d'un double * peut être différente de
| celle d'un void * ?

Oui.

| Si c'est vrai, malloc() ne fonctionne pas.

Quelle est la chaîne logique d'inférences qui t'amène à cette
conclusion ?


euh, perso je comprend *rien* à ce fil...

quelqu'un peut expliquer le probleme comme pour un gamin
de 5 ans ?

Avatar
Gabriel Dos Reis
Jean-Marc Bourguet writes:

| Yves ROMAN writes:
|
| > > Je ne vois pas pourquoi. La seule contrainte c'est que
| > > void* est capable de représenter précisément tous les types
| > > de pointeurs.
| >
| > Peut on donc dire, pour tout type de donnée T, que :
| > sizeof(void *) >= sizeof(T *) ?
|
| Ce n'est pas formel mais je ne vois pas de plateforme ou il aurait ete
| raisonnable que ce ne soit pas le cas.

Je crois qu'il y a des indications dans la norme qu'on peut déduire

sizeof (void*) == sizeof (char*) && sizeof (void*) >= sizeof (T*)

parce que void* doit pouvoir contenir des pointeurs sur n'importe quel
objet. Je crois également que C99 demande

sizeof (*S) == sizeof (T*), forall tags S, T.

-- Gaby
Avatar
Gabriel Dos Reis
Laurent Deniau writes:

| Marc Boyer wrote:
| > In article , Yves ROMAN wrote:
| >
| >>
| >>>Emmanuel Delahaye writes:
| >>>
| >>>
| >>>>Jean-Marc Bourguet wrote on 08/11/04 :
| >>>>
| >>>>>Quoi que void* n'ait pas la meme taille que double*? Oui.
| >>>>
| >>>>alors
| >>>>
| >>>>double *p = malloc (sizeof *p * 12);
| >>>>
| >>>>ne fonctionne pas ?
| >>>
| >>>Je ne vois pas pourquoi. La seule contrainte c'est que
| >>>void* est capable de représenter précisément tous les types
| >>>de pointeurs.
| >>>
| >>
| >>Peut on donc dire, pour tout type de donnée T, que :
| >>sizeof(void *) >= sizeof(T *) ?
| > Pourquoi ? On pourrait imaginer des bits de padding (ou de controle
| > de validité, on peut rèver) dans T* mais pas dans void*.
|
| Dans la pratique ca parait difficile. Quel padding mettrais-tu pour T*
| -> void* -> T* ? Qu'est ce que malloc renverrait?

malloc() renvoie un pointeur bien aligné pour tous les types objets,
donc ce n'est pas le problème.

-- Gaby
Avatar
Gabriel Dos Reis
Jean-Marc Bourguet writes:

| Laurent Deniau writes:
|
| > Jean-Marc Bourguet wrote:
| > > Laurent Deniau writes:
| > >
| > >>> Pourquoi ? On pourrait imaginer des bits de padding (ou de controle
| > >>>de validité, on peut rèver) dans T* mais pas dans void*.
| > >>
| > >>Dans la pratique ca parait difficile. Quel padding mettrais-tu pour T* ->
| > >>void* -> T* ? Qu'est ce que malloc renverrait?
| > > Tu peux imaginer qu'un T* comporte un pointeur brut (un void*) et un
| > > tag (un pointeur vers une description du type). Il y a eu des
| > > architecture a tag de meme qu'il y a eu des architectures ou pour
| > > toute indexation il fallait passer par un descripteur mais je n'en ai
| > > jamais regardees de pres donc je ne sais pas s'il y a eu des
| > > compilateurs C pour elles ni comment il fonctionnait.
| >
| > A quoi servirait ce tag?
|
| A ce qu'on veut. Imagine une machine concue pour executer du lisp

Comme SPARC ?
(non, les addresses ne sont pas taggées, mais certains entiers le sont
ey le but est de faciliter des implémentations de LISP.).

| avec de l'assistance hard, le tag peut etre necessaire pour faire qqch
| du pointeur mais pas pour trimbaler un void*. J'aurais tendance a
| trimbaler un tag specifique pour void* mais qui sait ce a quoi peuvent
| penser ceux qui ont concu l'ABI -- peut-etre a des cas auxquels moi je
| ne pense pas quand je fais de la speculation sur usenet.
|
| > Si T* -> void* est dans TU1 et void* -> T* est dans TU2, quel tag a
| > le T* de TU2?
|
| Le meme que le T* originel. Quel probleme?
|
| A+
|
| --
| Jean-Marc
| FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
| Site de usenet-fr: http://www.usenet-fr.news.eu.org

--
Gabriel Dos Reis

Texas A&M University -- Department of Computer Science
301, Bright Building -- College Station, TX 77843-3112
Avatar
Gabriel Dos Reis
"Charlie Gordon" writes:

| "Gabriel Dos Reis" wrote in message
| news:
| > "Charlie Gordon" writes:
| >
| > | > Non, cela n'initialise pas les champs, mais met tous les bits à 0. En
| > | > particulier pour les flottants (float, double, ...) et les pointeurs, il
| > | > n'y a aucune garantie que cela corresponde à des valeurs nulles.
| > |
| > | Les initialiser à all-bit-zero, c'est toujours mieux que de les laisser à
| > | garbage.
| >
| > ce n'est pas une meilleure stupidité -- c'est juste une autre
| > stupidité -- car...
|
| Comment peux-tu soutenir une telle position !

Je venais juste de le faire, donc tu as vu le « comment » :-)

| C'est moins risqué d'avoir un contenu fixe, en l'occurrence connu, que n'importe
| quel garbage variable et non reproductible !

Je ne suis pas d'accord avec le « moins risqué ». Cela donne un faux
sens de sécurité. C'est une autre stupidité, peut-être moins
apparante, mais c'est quand même une stupidité.

| Bien sûr le comportement sera incorrect lors de certains portages, au moins
| sera-t-il très probablement systématique.

Ce n'est pas mon expérience. En fait, même sans portage. À un
moment donné, avec GCC, cetains ont même proposé que les variables
soient initialisées avec des garbages apparents (et non all-bits zero).

| Ce qui est stupide, c'est d'utiliser des variables qui sont potentiellement
| invalides.

Oui, et les cacher est aussi stupide.

| Faire en sorte que ce type de bug soit plus facile à trouver, je ne trouve pas
| cela stupide.
| Les programmeurs sont *tous* beugués, et certains plus que les autres.
|
| > | Quant aux flottants, s'ils sont IEEE, 0 = all-bits-zero.
| >
| > Bah non. Le format IEEE-756 n'est qu'un modèle mathématique et non une
| > exigence hardware. Le comité C a fait la même bêtise avant de se
| > rattraper.
|
| Oui, OK, il faut être précis.
| Mais connais-tu une implémentation conforme où 'all-bit-zero' n'est pas une
| représentation de 0.0 ?
|
| > | Mais bien sûr on peut trouver des archi exotiques.
| >
| > Je suppose que tu appelles « exotique », ce qui n'est pas encore
| > rentré dans ta connaissance/culture -- dont l'étendue soulève des
| > questions ;-)
|
| Ethymologiquement, tu as presque raison, mais le sens ne dépend pas de la
| culture du locuteur.

Certains de mes collègues à Paris et ici pensent que je viens d'un
pays exotique. Mais concitoyens ne sont pas de cet avis.

[...]

| D'ailleurs, comment pourrais-je participer au comité de normalisation du C ?

Contacte l'AFNOR -- si tu veux representer la France.

-- Gaby
.
Avatar
Jean-Marc Bourguet
Gabriel Dos Reis writes:

Jean-Marc Bourguet writes:

| Yves ROMAN writes:
|
| > > Je ne vois pas pourquoi. La seule contrainte c'est que
| > > void* est capable de représenter précisément tous les types
| > > de pointeurs.
| >
| > Peut on donc dire, pour tout type de donnée T, que :
| > sizeof(void *) >= sizeof(T *) ?
|
| Ce n'est pas formel mais je ne vois pas de plateforme ou il aurait ete
| raisonnable que ce ne soit pas le cas.

Je crois qu'il y a des indications dans la norme qu'on peut déduire

sizeof (void*) == sizeof (char*)


Il me semble me souvenir de ca.

&& sizeof (void*) >= sizeof (T*)


Mais pas de ca. Mais je n'ai pas refais un exegese pour ces reponses.

parce que void* doit pouvoir contenir des pointeurs sur n'importe quel
objet. Je crois également que C99 demande

sizeof (*S) == sizeof (T*), forall tags S, T.


Ca me semble difficile de faire autrement en ayant de la compilation
independante comme on a la possibilite d'avoir des pointeurs sur des
struct dont on ne connait que le tag.

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Avatar
Jean-Marc Bourguet
Gabriel Dos Reis writes:

Jean-Marc Bourguet writes:
| A ce qu'on veut. Imagine une machine concue pour executer du lisp

Comme SPARC ?
(non, les addresses ne sont pas taggées, mais certains entiers le sont
ey le but est de faciliter des implémentations de LISP.).


Je sais mais je ne pensais pas a ca. Il me semble me souvenir de
discussions (auxquelles je n'ai pas participe) avec des implementeurs
de lisp sur comp.arch ou ils expliquaient pourquoi ces instructions
n'etaient pas utilisees dans leur implementation.

Je pensais plutot a un support du genre de ceux des annees 70 pour les
langages de haut niveau.

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Avatar
Jean-Marc Bourguet
Laurent Deniau writes:

A quoi servirait ce tag?
A ce qu'on veut. Imagine une machine concue pour executer du lisp

avec de l'assistance hard, le tag peut etre necessaire pour faire qqch
du pointeur mais pas pour trimbaler un void*. J'aurais tendance a


Il me semble que sur Lisp, les types de base ont chacun un tas
specialise donc il n'est pas necessaire d'utiliser un tag pour
determiner le type du pointeur.


C'est une implementation possible. Une autre est d'utiliser le fait
que les pointeurs sont alignes et donc mettre un tag dans les bits de
poids faible.

Le meme que le T* originel. Quel probleme?


Quel est le tag du T* originel issu de malloc()?


malloc renvoie un void*, donc sans tag.

Comment T* et void* peuvent avoir des tailles differentes dans ce cas?


t* est un struct {
tag* the_tag;
void* the_value;
};

Un cast met le tag adequat.

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org



Avatar
Marc Boyer
Gabriel Dos Reis wrote:
Jean-Marc Bourguet writes:

| Yves ROMAN writes:
|
| > > Je ne vois pas pourquoi. La seule contrainte c'est que
| > > void* est capable de représenter précisément tous les types
| > > de pointeurs.
| >
| > Peut on donc dire, pour tout type de donnée T, que :
| > sizeof(void *) >= sizeof(T *) ?
|
| Ce n'est pas formel mais je ne vois pas de plateforme ou il aurait ete
| raisonnable que ce ne soit pas le cas.

Je crois qu'il y a des indications dans la norme qu'on peut déduire

sizeof (void*) == sizeof (char*)


6.2.5/26
A pointer to void shall have the same representation and alignment
requirements as a pointer to a character type.

&& sizeof (void*) >= sizeof (T*)


Ca, j'ai pas vu.

Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.

Avatar
Antoine Leca
En , Gabriel Dos Reis va escriure:
Je crois qu'il y a des indications dans la norme qu'on peut déduire

sizeof (void*) >= sizeof (T*)

parce que void* doit pouvoir contenir des pointeurs sur n'importe quel
objet.


Penses-tu à 6.3.2.3p1

A pointer to /void/ may be converted to or from a pointer to any
incomplete or object type. A pointer to any incomplete or object
type may be converted to a pointer to /void/ and back again; the
result shall compare equal to the original pointer.

Autrement dit ce n'est pas symétrique, la conversion void* => T* ne peut pas
ajouter d'information extérieure (entropie).

Cela étant, cela n'est pas une contrainte sur la représentation des objets.
Comme le disait Jean-Marc, on peut y ajouter des informations de validation
du type T*, par exemple; ou un pointeur vers une fonction de debug qui sait
afficher le contenu de l'objet pointé. Vois pas le souci.


Antoine

5 6 7 8 9