pourquoi est-u8 u16 u32 u64 utilisé à la place de unsigned int dans le noyau de la programmation

Je vois u8 u16 u32 u64 types de données utilisés dans le code du noyau. Et je me demande pourquoi il y a besoin d'utiliser u8 ou u16 ou u32 ou u64 et pas unsigned int?

Qu'carte à de votre liste. Et vous ne pouvez pas être sûr que l'on.
J'ai surtout vu la norme typedefs uint8_t, uint16_t, et al.
J'ai un linux/types d'.h comprennent

OriginalL'auteur | 2015-06-17

  1. 14

    Souvent lorsque vous travaillez à proximité du matériel ou lorsque vous essayez de contrôler la taille et le format de la structure des données, vous devez avoir un contrôle précis de la taille de votre entiers.

    Comme pour u8 vs uint8_t, c'est tout simplement parce que Linux a précédé <stdint.h> être disponible en C, ce qui est techniquement un C99-ism, mais dans mon expérience est disponible sur la plupart des les compilateurs modernes, même dans leur ANSI-C /C89 modes.

    Et u8 implique moins de frappe 🙂
    Vrai... mais il est super gênant quand vous avez besoin de mix & match de bibliothèques et tout le monde essaie de définir leurs propres connu-wdith types. Vous aurez U8, u8, uint8, BYTE, UINT8 et unt8_t tous dans le même fichier. Vous pouvez même avoir des conflits potentiels qui finit par générer des avertissements. Le plus souvent avec le 32 et 64 bits types qui peuvent avoir de multiples moyens valables pour typedef sur une plate-forme donnée. Pour le nouveau code, s'il vous plaît, s'il vous plaît, il suffit de coller avec stdint.sous-types h :).
    Je suis à l'aide de u8 u16 etc dans l'espace noyau avec linux/types.h. Est stdint.h pour l'utilisateur de l'espace?
    Vous pouvez utiliser les noms standard (uint8_t, etc) en mode noyau. Typedefs pour ceux qui sont dans linux/types.h.
    aussi longtemps que u8 etc sont à votre typedefs que vous pouvez garantie sont identiques à la norme, vous serez amende. Comme Gil Hamilton, le noyau n'ceci

    OriginalL'auteur Brian McFarland

  2. 2

    L'ajout de mes 10 cents à cette réponse:

    u64 signifie un " unsigned 64 bits de valeur, de sorte que, en fonction de l'architecture où le code sera exécuté/être compilé, il doit être défini de façon à être vraiment 64 bits.

    Par exemple, sur une machine x86, un unsigned long est de 64 bits, donc u64 pour que la machine peut être définie comme suit:

    typedef unsigned long u64;

    La même chose s'applique pour u32. Sur une machine x86, unsigned int est une longueur de 32 bits, donc u32 pour que la machine peut être définie comme suit:

    typedef unsigned int u32;

    Vous retrouverez généralement le typedef déclaration pour ces types sur un types.h fichier qui correspond à l'architecture vous êtes de la compilation de votre source.

    OriginalL'auteur Alexandre Schmidt