ARM cortex-M3 uint_fast32_t vs uint32_t

Je développe un programme pour un processeur de la série cortex-M3 STM32Fx. Dans stdint.h, les éléments suivants sont définis:

typedef unsigned int uint_fast32_t; typedef uint32_t uint_least32_t; typedef unsigned long uint32_t; 

Si je comprends bien.

 [u]int_fast[n]_t will give you the fastest data type of at least n bits. [u]int_least[n]_t will give you the smallest data type of at least n bits. [u]int[n]_t will give you the data type of exactly n bits. 

Aussi, autant que je sache, sizeof (unsigned int) <= sizeof (unsigned long) et UINT_MAX <= ULONG_MAX – toujours.

Donc, je m’attendrais à ce que uint_fast32_t soit un type de données avec une taille égale ou supérieure à la taille de uint32_t.

Dans le cas du cortex-M3, sizeof (unsigned int) == sizeof (unsigned long) == 4. Les définitions ci-dessus sont donc “correctes” en termes de taille.

Mais pourquoi ne sont-ils pas définis de manière cohérente avec les noms et les tailles logiques des types de données sous-jacents, c’est-à-dire

 typedef unsigned long uint_fast32_t; typedef unsigned int uint_least32_t; typedef uint_fast32_t uint32_t; 

Quelqu’un peut-il s’il vous plaît clarifier la sélection des types sous-jacents?

Étant donné que “long” et “int” ont la même taille, pourquoi ne pas utiliser le même type de données pour les trois définitions?

 typedef unsigned int uint_fast32_t; typedef unsigned int uint_least32_t; typedef unsigned int uint32_t; 

Le cas est, il est seulement garanti que

 sizeof(long) >= sizeof(int) 

et il n’est pas garanti que ce soit effectivement plus longtemps. Sur beaucoup de systèmes, int est généralement aussi gros que long.

Voir ma réponse à votre autre question .

Fondamentalement, peu importe le type utilisé. Etant donné que int et long ont la même taille et ont la même représentation et d’autres caractéristiques, le responsable de la mise en œuvre peut choisir le type pour int32_t , int_fast32_t et int_least32_t , ainsi que pour les versions non signées correspondantes.

(Il est possible que les choix particuliers soient influencés par le besoin ressenti d’utiliser le même en-tête pour des implémentations de tailles différentes pour les tailles int et long , mais je ne vois pas comment les définitions particulières que vous avez citées permettraient d’atteindre cet objective.)

Tant que les types ont la bonne taille et répondent à toutes les autres exigences imposées par la norme, et tant que vous n’écrivez pas de code qui dépend, par exemple, de la compatibilité de int32_t avec int ou de long , il ‘n t importe.

Les choix particuliers qui ont été faits étaient probablement le caprice de l’applicateur, ce qui est parfaitement acceptable. Ou peut-être que ce fichier d’en-tête a été modifié par deux développeurs ou plus qui avaient des idées différentes sur le type le mieux adapté.