Quand uint8_t ≠ est un caractère non signé ?

Question

Selon le C et le C++, CHAR_BIT >= 8 .
Mais à chaque fois que CHAR_BIT > 8 , uint8_t ne peut même pas être représenté par 8 bits.
Il doit être plus grand, car CHAR_BIT est le nombre minimum de bits pour tout type de données sur le système.

Sur quel type de système peut-on uint8_t être légalement défini comme étant un type autre que unsigned char ?

(Si la réponse est différente pour le C et le C++, alors j'aimerais connaître les deux).

Answer 1

Si elle existe, uint8_t doit toujours avoir la même largeur que unsigned char . Toutefois, il ne doit pas nécessairement s'agir du même type ; il peut s'agir d'un type d'entier étendu distinct. Il ne doit pas non plus avoir la même représentation que unsigned char ; par exemple, les bits pourraient être interprétés dans l'ordre inverse. C'est un exemple stupide, mais il est plus logique pour int8_t où signed char peut être un complément ou un signe-magnitude alors que int8_t doit être un complément à deux.

Un autre " avantage " de l'utilisation d'un type d'entier étendu non carné pour uint8_t même sur les systèmes "normaux" est la règle d'aliasing de C. Les types de caractères sont autorisés à aliaser n'importe quoi, ce qui empêche le compilateur d'optimiser fortement les fonctions qui utilisent à la fois des pointeurs de caractères et des pointeurs vers d'autres types, à moins que l'attribut restrict Le mot clé a été bien appliqué. Cependant, même si uint8_t a exactement la même taille et la même représentation que unsigned char si l'implémentation en faisait un type distinct, sans caractère, les règles d'aliasing ne s'appliqueraient pas à lui, et le compilateur pourrait supposer que les objets de types uint8_t y int par exemple, ne peut jamais aliaser.

Answer 2

Jamais. char , signed char y unsigned char sont les plus petites unités adressables, et int8_t y uint8_t ne peut pas avoir de bits de remplissage. Ainsi, si CHAR_BIT > 8 ces types ne peuvent pas exister.

---

Voici ce que dit le projet de norme C11 (n1570.pdf) :

6.5.3.4 Les opérateurs sizeof et _Alignof

...

4 Lorsque sizeof est appliqué à un opérande qui a le type char, unsigned char, ou char signé, (ou une version qualifiée de celui-ci) le résultat est 1. ...

Ce sont donc les plus petites unités adressables.

7.20.1.1 Types d'entiers de largeur exacte

1 Le nom typedef intN_t désigne un type de nombre entier signé de largeur N, sans bits de remplissage, et une représentation en complément à deux. Ainsi , int8_t désigne un tel type de nombre entier signé avec une largeur d'exactement 8 bits.

2 Le nom de type uintN_t désigne un type d'entier non signé avec une largeur largeur N et sans bits de remplissage. Ainsi, uint24_t désigne un type entier non signé de largeur avec une largeur d'exactement 24 bits.

3 Ces types sont facultatifs. Cependant, si une implémentation fournit des types entiers d'une largeur de 8, 16, 32 ou 64 bits, sans bits de remplissage, et (pour les types signés) qui ont une représentation en complément à deux elle doit définir les noms de typedef correspondants.

Answer 3

Une possibilité que personne n'a évoquée jusqu'à présent : si CHAR_BIT==8 et sans réserve char est non signé, ce qui est le cas dans certains ABI, alors uint8_t pourrait être un typedef pour char au lieu de unsigned char . Ceci est important au moins dans la mesure où cela affecte le choix de la surcharge (et son jumeau diabolique, la manipulation des noms), c'est-à-dire que si vous aviez à la fois foo(char) y foo(unsigned char) dans le champ d'application, en appelant foo avec un argument de type uint8_t préférerait foo(char) sur un tel système.