Type de champs binarys non signés: int ou unsigned int

La section 6.3.1.1 de la norme C99 contient:

Les éléments suivants peuvent être utilisés dans une expression partout où un int ou un unsigned int peut être utilisé:

[…] Un champ de bits de type _Bool , int , signed int ou unsigned int .

Si un int peut représenter toutes les valeurs du type d’origine, la valeur est convertie en un int ; sinon, il est converti en un unsigned int .

Il me semble que cela implique que les champs de bits unsigned int sont promus en int , sauf lorsque la largeur du champ de bits non signé est égale à la largeur de int , auquel cas la dernière phrase s’applique.

J’ai le programme suivant:

 struct S { unsigned f:32; } x = { 28349}; unsigned short us = 0xDC23L; main(){ int r = (xf ^ ((short)-87)) >= us; printf("%d\n", r); return r; } 

Et deux systèmes pour exécuter ce programme ( int est 32 bits sur les deux systèmes). Un système indique que ce programme imprime 1, et l’autre indique 0. Ma question est la suivante: contre lequel des deux systèmes dois-je déposer un rapport de bogue? (Je penche vers le repository du rapport contre le système qui affiche 0, à cause de l’extrait ci-dessus)

Il semble que cette ambiguïté ait déjà été détectée par le comité de normalisation puisque le projet actuel clarifie cette phrase:

Si un int peut représenter toutes les valeurs du type d’origine (comme le limite la largeur, pour un champ de bits), la valeur est convertie en un entier;

Ma lecture est la même que vous: un champ de bits non signé de la taille d’un int doit avoir un type non signé, comme un type, plus petit qu’un entier, un type signé.

Les compilateurs auxquels j’ai access (gcc sur x86, Sun CC sur Sparc, IBM xlC sur POWER) ont un comportement correspondant à cette lecture (impression 1 dans votre programme, impression 0 si le champ binary est réduit à 31 bits ou signé).