Quelle est la taille de cette structure? et pourquoi?

le programme suivant donne la sortie 4. Je pensais qu'il produirait 8 sizeof (int) + sizeof (unsigned int)

#include
#include
int main()
{
        struct node
        {
                int a;
                struct node * next;
        };
        struct node * p= (struct node *) malloc( sizeof( struct node));
        printf("%d", sizeof( p));
}
1
Vous prenez la taille du pointeur au lieu de l'objet lui-même.
ajouté l'auteur Mysticial, source
Il est également important de savoir si vous compilez ceci pour 32 bits ou 64 bits, car cela fait une différence quant à la taille du int et des pointeurs.
ajouté l'auteur Raceimaztion, source
Il est également important de savoir si vous compilez ceci pour 32 bits ou 64 bits, car cela fait une différence quant à la taille du int et des pointeurs.
ajouté l'auteur Raceimaztion, source

6 Réponses

Dans ce code, p est un pointeur. Vous n'imprimez donc que la taille d'un pointeur (qui correspond apparemment à 4 octets dans votre combinaison compilateur/système d'exploitation). Si vous souhaitez connaître la taille de la structure, vous devez imprimer sizeof (* p) . En outre, comme il a été souligné, l'utilisation de "% d" pour un size_t ne fonctionnera pas nécessairement ("% zu" est correct, bien que% d fonctionne sur la plupart des compilateurs/systèmes d'exploitation du monde réel). En outre, vous ne devriez pas supposer que la taille de la structure "devrait" être 8. Les pointeurs peuvent être plus grands, ou le compilateur peut vouloir compléter ou aligner la structure de façon étrange.

2
ajouté

Dans ce code, p est un pointeur. Vous n'imprimez donc que la taille d'un pointeur (qui correspond apparemment à 4 octets dans votre combinaison compilateur/système d'exploitation). Si vous souhaitez connaître la taille de la structure, vous devez imprimer sizeof (* p) . En outre, comme il a été souligné, l'utilisation de "% d" pour un size_t ne fonctionnera pas nécessairement ("% zu" est correct, bien que% d fonctionne sur la plupart des compilateurs/systèmes d'exploitation du monde réel). En outre, vous ne devriez pas supposer que la taille de la structure "devrait" être 8. Les pointeurs peuvent être plus grands, ou le compilateur peut vouloir compléter ou aligner la structure de façon étrange.

2
ajouté

p is just a pointer. Its size depends on ABI, which is in your case 4.

1
ajouté
Vous avez raison, c'est la taille du pointeur. Vous avez tort de supposer quelle est cette taille.
ajouté l'auteur Genia S., source
Non, ce sera la taille d'un pointeur, qui peut être ou non la taille d'un entier non signé.
ajouté l'auteur Lee Daniel Crocker, source

p is just a pointer. Its size depends on ABI, which is in your case 4.

1
ajouté
Vous avez raison, c'est la taille du pointeur. Vous avez tort de supposer quelle est cette taille.
ajouté l'auteur Genia S., source
Non, ce sera la taille d'un pointeur, qui peut être ou non la taille d'un entier non signé.
ajouté l'auteur Lee Daniel Crocker, source

Et la réponse correcte : votre sortie, le cas échéant, est indéterminée, car vous utilisez le spécificateur de format incorrect dans l'appel à printf() . Vous auriez dû utiliser % zu à la place - sizeof() renvoie un objet de type size_t .

Ainsi, votre programme invoque le comportement non défini et il est libre de faire (et d’imprimer) tout ce qu’il veut.

1
ajouté
Le fait est que sizeof (x) ne donne pas un unsigned int , mais un size_t . Sur la plupart des systèmes, cela ressemble à un unsigned int , mais ce n’est pas obligatoire. % zu est le spécificateur de format approprié pour un size_t , alors que % d peut entraîner des événements catastrophiques.
ajouté l'auteur amalloy, source
Je crois que la conversion d'un entier non signé en entier n'entraînera pas un comportement indéfini. Cela pourrait convertir quelque chose comme 255 en quelque chose comme -127 sur des systèmes 8 bits. Pas sûr cependant. Une source au comportement indéfini serait grandement appréciée!
ajouté l'auteur Atmaram Shetye, source

Et la réponse correcte : votre sortie, le cas échéant, est indéterminée, car vous utilisez le spécificateur de format incorrect dans l'appel à printf() . Vous auriez dû utiliser % zu à la place - sizeof() renvoie un objet de type size_t .

Ainsi, votre programme invoque le comportement non défini et il est libre de faire (et d’imprimer) tout ce qu’il veut.

1
ajouté
Le fait est que sizeof (x) ne donne pas un unsigned int , mais un size_t . Sur la plupart des systèmes, cela ressemble à un unsigned int , mais ce n’est pas obligatoire. % zu est le spécificateur de format approprié pour un size_t , alors que % d peut entraîner des événements catastrophiques.
ajouté l'auteur amalloy, source
Je crois que la conversion d'un entier non signé en entier n'entraînera pas un comportement indéfini. Cela pourrait convertir quelque chose comme 255 en quelque chose comme -127 sur des systèmes 8 bits. Pas sûr cependant. Une source au comportement indéfini serait grandement appréciée!
ajouté l'auteur Atmaram Shetye, source