Pourquoi attribuer une valeur à un champ de bits ne renvoie-t-il pas la même valeur?

J'ai vu le code ci-dessous dans cet article Quora :

#include <stdio.h>

struct mystruct { int enabled:1; };
int main()
{
  struct mystruct s;
  s.enabled = 1;
  if(s.enabled == 1)
    printf("Is enabled\n"); // --> we think this to be printed
  else
    printf("Is disabled !!\n");
}

En C et C ++, la sortie du code est inattendue ,

Est désactivé !!

Bien que l'explication relative au "bit de signe" soit donnée dans ce post, je suis incapable de comprendre comment il est possible que nous définissions quelque chose et que cela ne reflète pas tel quel.

Quelqu'un peut-il donner une explication plus élaborée?

Remarque : les deux balisesc & c ++sont nécessaires, car leurs normes diffèrent légèrement pour décrire les champs de bits. Voir les réponses pour la spécification C et la spécification C ++ .

Les champs de bits sont incroyablement mal définis par la norme. Compte tenu de ce code struct mystruct {int enabled:1;};, alors nous ne savons pas :

• Combien d'espace cela occupe - s'il y a des bits / octets de remplissage et où ils se trouvent dans la mémoire.
• Où le bit est situé en mémoire. Non défini et dépend également de l'endianess.
• int:nIndique si un champ de bits doit être considéré comme signé ou non signé.

Concernant la dernière partie, C17 6.7.2.1/10 dit:

Un champ de bits est interprété comme ayant un type entier signé ou non signé constitué du nombre spécifié de bits ¹²⁵⁾

Note non normative expliquant ce qui précède:

¹²⁵⁾ Comme spécifié au 6.7.2 ci-dessus, si le spécificateur de type réel utilisé est intou un typedef-name défini comme int, alors il est défini par l'implémentation si le champ de bits est signé ou non signé.

Dans le cas où le champ de signed intbits doit être considéré comme et que vous faites un peu de taille 1, alors il n'y a pas de place pour les données, uniquement pour le bit de signe. C'est la raison pour laquelle votre programme peut donner des résultats étranges sur certains compilateurs.

Bonnes pratiques:

• N'utilisez jamais de champs de bits pour quelque raison que ce soit.
• Évitez d'utiliser le inttype signé pour toute forme de manipulation de bits.

Je suis incapable de comprendre, comment est-il possible que nous définissions quelque chose et que cela n'apparaisse pas tel quel.

Vous demandez-vous pourquoi il compile et vous donne une erreur?

Oui, cela devrait idéalement vous donner une erreur. Et c'est le cas, si vous utilisez les avertissements de votre compilateur. Dans GCC, avec -Werror -Wall -pedantic:

main.cpp: In function 'int main()':
main.cpp:7:15: error: overflow in conversion from 'int' to 'signed char:1' 
changes value from '1' to '-1' [-Werror=overflow]
   s.enabled = 1;
           ^

La raison pour laquelle cela est laissé à la définition de l'implémentation par rapport à une erreur peut avoir plus à voir avec les utilisations historiques, où exiger un cast signifierait casser l'ancien code. Les auteurs de la norme peuvent penser que les avertissements ont suffi à combler les lacunes des personnes concernées.

Pour ajouter un peu de prescriptivisme, je ferai écho à la déclaration de @ Lundin: "N'utilisez jamais de champs de bits pour quelque raison que ce soit." Si vous avez le genre de bonnes raisons d'obtenir des détails de bas niveau et spécifiques sur la disposition de votre mémoire qui vous amèneraient à penser que vous aviez besoin de champs de bits en premier lieu, les autres exigences associées que vous avez presque certainement se heurteront à leur sous-spécification.

(TL; DR - Si vous êtes assez sophistiqué pour légitimement «avoir besoin» de champs de bits, ils ne sont pas assez bien définis pour vous servir.)

Il s'agit d'un comportement défini par l'implémentation. Je suppose que les machines sur lesquelles vous exécutez ceci utilisent des entiers signés à complément double et les traitent intdans ce cas comme un entier signé pour expliquer pourquoi vous n'entrez pas si une partie vraie de l'instruction if.

struct mystruct { int enabled:1; };

déclare enablecomme un champ de bits de 1 bit. Puisqu'il est signé, les valeurs valides sont -1et 0. Définir le champ sur les 1débordements de ce bit -1(il s'agit d'un comportement non défini)

Essentiellement, lorsqu'il s'agit d'un champ de bits signé, la valeur maximale est 2^(bits - 1) - 1ce qui est 0dans ce cas.

Vous pourriez penser que dans le système de complément à 2, le bit le plus à gauche est le bit de signe. Tout entier signé avec le bit le plus à gauche est donc une valeur négative.

Si vous avez un entier signé de 1 bit, il n'a que le bit de signe. L'attribution 1de ce bit unique ne peut donc définir que le bit de signe. Ainsi, lors de sa relecture, la valeur est interprétée comme négative, tout comme -1.

Les valeurs qu'un entier signé de 1 bit peut contenir sont -2^(n-1)= -2^(1-1)= -2^0= -1et2^n-1= 2^1-1=0

Conformément à la norme C ++ n4713 , un extrait de code très similaire est fourni. Le type utilisé est BOOL(personnalisé), mais il peut s'appliquer à n'importe quel type.

12.2.4

⁴ Si la valeur true ou false est stockée dans un champ de bits de typeboolde n'importe quelle taille (y compris un champ de bits d'un bit), laboolvaleur d'origineet la valeur du champ de bits doivent être comparées égales. Si la valeur d'un énumérateur est stockée dans un champ de bits du même type d'énumération et que le nombre de bits dans le champ de bits est suffisamment grand pour contenir toutes les valeurs de ce type d'énumération (10.2), la valeur de l'énumérateur d'origine et le la valeur du champ de bits doit être comparée égale . [ Exemple:

enum BOOL { FALSE=0, TRUE=1 };
struct A {
  BOOL b:1;
};
A a;
void f() {
  a.b = TRUE;
  if (a.b == TRUE)    // yields true
    { /* ... */ }
}

- fin d'exemple]

Au premier coup d'œil, la partie en gras semble ouverte à l'interprétation. Cependant, l'intention correcte devient claire lorsque le enum BOOLest dérivé du int.

enum BOOL : int { FALSE=0, TRUE=1 }; // ***this line
struct mystruct { BOOL enabled:1; };
int main()
{
  struct mystruct s;
  s.enabled = TRUE;
  if(s.enabled == TRUE)
    printf("Is enabled\n"); // --> we think this to be printed
  else
    printf("Is disabled !!\n");
}

Avec le code ci-dessus, il donne un avertissement sans -Wall -pedantic:

avertissement: 'mystruct :: enabled' est trop petit pour contenir toutes les valeurs de 'enum BOOL' struct mystruct { BOOL enabled:1; };

La sortie est:

Est désactivé !! (lors de l'utilisation enum BOOL : int)

Si enum BOOL : intest simplifié enum BOOL, alors la sortie est comme le spécifie le pasage standard ci-dessus:

Est activé (lors de l'utilisation enum BOOL)

Par conséquent, il peut être conclu, comme peu d'autres réponses l'ont fait, que le inttype n'est pas assez grand pour stocker la valeur "1" dans un seul champ de bits.

Il n'y a rien de mal dans votre compréhension des champs de bits que je peux voir. Ce que je vois, c'est que vous avez redéfini mystruct d'abord comme struct mystruct {int enabled: 1; } puis comme struct mystruct s; . Ce que vous auriez dû coder était:

#include <stdio.h>

struct mystruct { int enabled:1; };
int main()
{
    mystruct s; <-- Get rid of "struct" type declaration
    s.enabled = 1;
    if(s.enabled == 1)
        printf("Is enabled\n"); // --> we think this to be printed
    else
        printf("Is disabled !!\n");
}