Existe-t-il un moyen programmatique de détecter si vous êtes ou non sur une architecture big-endian ou little-endian? J'ai besoin d'être en mesure d'écrire du code qui s'exécutera sur un système Intel ou PPC et d'utiliser exactement le même code (c'est-à-dire pas de compilation conditionnelle).

Je n'aime pas la méthode basée sur le type punning - elle sera souvent mise en garde par le compilateur. C'est exactement à cela que servent les syndicats!

bool is_big_endian(void)
{
    union {
        uint32_t i;
        char c[4];
    } bint = {0x01020304};

    return bint.c[0] == 1; 
}

Le principe est équivalent au cas type comme suggéré par d'autres, mais c'est plus clair - et selon C99, il est garanti d'être correct. gcc préfère cela par rapport à la distribution de pointeur direct.

C'est aussi bien mieux que de corriger l'endianité au moment de la compilation - pour les OS qui prennent en charge la multi-architecture (binaire gras sur Mac os x par exemple), cela fonctionnera pour les deux ppc / i386, alors qu'il est très facile de gâcher les choses autrement .

Vous pouvez le faire en définissant un int et en masquant les bits, mais le moyen le plus simple est probablement d'utiliser les opérations de conversion d'octets réseau intégrées (car l'ordre des octets réseau est toujours en gros bout).

if ( htonl(47) == 47 ) {
  // Big endian
} else {
  // Little endian.
}

Le bricolage des bits pourrait être plus rapide, mais cette façon est simple, directe et assez impossible à gâcher.

Veuillez consulter cet article :

Voici un code pour déterminer quel est le type de votre machine

int num = 1;
if(*(char *)&num == 1)
{
    printf("\nLittle-Endian\n");
}
else
{
    printf("Big-Endian\n");
}

Vous pouvez utiliser std::endiansi vous avez accès au compilateur C ++ 20 tel que GCC 8+ ou Clang 7+.

Remarque: a std::endiancommencé en <type_traits>mais a été déplacé à la <bit>réunion de Cologne 2019. GCC 8, Clang 7, 8 et 9 l'ont en place <type_traits>tandis que GCC 9+ et Clang 10+ l'ont <bit>.

#include <bit>

if constexpr (std::endian::native == std::endian::big)
{
    // Big endian system
}
else if constexpr (std::endian::native == std::endian::little)
{
    // Little endian system
}
else
{
    // Something else
}

Cela se fait normalement au moment de la compilation (spécialement pour des raisons de performances) en utilisant les fichiers d'en-tête disponibles à partir du compilateur ou créez les vôtres. Sous Linux, vous avez le fichier d'en-tête "/usr/include/endian.h"

Je suis surpris que personne n'ait mentionné les macros que le préprocesseur définit par défaut. Bien que ceux-ci varient en fonction de votre plate-forme; ils sont beaucoup plus propres que d'avoir à faire votre propre chèque endian.

Par exemple; si nous regardons les macros intégrées définies par GCC (sur une machine X86-64):

:| gcc -dM -E -x c - |grep -i endian
#define __LITTLE_ENDIAN__ 1

Sur une machine PPC j'obtiens:

:| gcc -dM -E -x c - |grep -i endian
#define __BIG_ENDIAN__ 1
#define _BIG_ENDIAN 1

(La :| gcc -dM -E -x c -magie imprime toutes les macros intégrées).

Ehm ... Cela me surprend que personne ne se soit rendu compte que le compilateur optimisera simplement le test et mettra un résultat fixe comme valeur de retour. Cela rend tous les exemples de code ci-dessus, effectivement inutiles. La seule chose qui serait retournée est l'endianité à la compilation! Et oui, j'ai testé tous les exemples ci-dessus. Voici un exemple avec MSVC 9.0 (Visual Studio 2008).

Code C pur

int32 DNA_GetEndianness(void)
{
    union 
    {
        uint8  c[4];
        uint32 i;
    } u;

    u.i = 0x01020304;

    if (0x04 == u.c[0])
        return DNA_ENDIAN_LITTLE;
    else if (0x01 == u.c[0])
        return DNA_ENDIAN_BIG;
    else
        return DNA_ENDIAN_UNKNOWN;
}

Démontage

PUBLIC  _DNA_GetEndianness
; Function compile flags: /Ogtpy
; File c:\development\dna\source\libraries\dna\endian.c
;   COMDAT _DNA_GetEndianness
_TEXT   SEGMENT
_DNA_GetEndianness PROC                 ; COMDAT

; 11   :     union 
; 12   :     {
; 13   :         uint8  c[4];
; 14   :         uint32 i;
; 15   :     } u;
; 16   : 
; 17   :     u.i = 1;
; 18   : 
; 19   :     if (1 == u.c[0])
; 20   :         return DNA_ENDIAN_LITTLE;

    mov eax, 1

; 21   :     else if (1 == u.c[3])
; 22   :         return DNA_ENDIAN_BIG;
; 23   :     else
; 24   :        return DNA_ENDIAN_UNKNOWN;
; 25   : }

    ret
_DNA_GetEndianness ENDP
END

Il est peut-être possible de désactiver N'IMPORTE QUELLE optimisation au moment de la compilation pour cette fonction, mais je ne sais pas. Sinon, il est peut-être possible de le coder en dur dans l'assemblage, bien que ce ne soit pas portable. Et même alors, même cela pourrait être optimisé. Cela me fait penser que j'ai besoin d'un assembleur vraiment merdique, d'implémenter le même code pour tous les CPU / jeux d'instructions existants, et bien ... tant pis.

De plus, quelqu'un ici a dit que l'endianisme ne change pas pendant l'exécution. FAUX. Il existe des machines bi-endiennes. Leur endianité peut varier pendant l'exécution. AUSSI, il n'y a pas seulement le Little Endian et le Big Endian, mais aussi d'autres endiannesses (quel mot).

Je déteste et j'adore coder en même temps ...

Déclarez une variable int:

int variable = 0xFF;

Utilisez maintenant des pointeurs char * vers différentes parties de celui-ci et vérifiez ce qu'il y a dans ces parties.

char* startPart = reinterpret_cast<char*>( &variable );
char* endPart = reinterpret_cast<char*>( &variable ) + sizeof( int ) - 1;

En fonction de celui qui pointe vers l'octet 0xFF, vous pouvez maintenant détecter l'endianité. Cela nécessite sizeof (int)> sizeof (char), mais c'est certainement vrai pour les plateformes discutées.

Pour plus de détails, vous pouvez consulter cet article de projet de code Concepts de base sur l'endianité :

Comment tester dynamiquement le type Endian au moment de l'exécution?

Comme expliqué dans la FAQ sur l'animation par ordinateur, vous pouvez utiliser la fonction suivante pour voir si votre code s'exécute sur un système Little ou Big-Endian: Réduire

#define BIG_ENDIAN      0
#define LITTLE_ENDIAN   1

int TestByteOrder()
{
   short int word = 0x0001;
   char *byte = (char *) &word;
   return(byte[0] ? LITTLE_ENDIAN : BIG_ENDIAN);
}

Ce code attribue la valeur 0001h à un entier 16 bits. Un pointeur char est ensuite affecté pour pointer sur le premier octet (le moins significatif) de la valeur entière. Si le premier octet de l'entier est 0x01h, alors le système est Little-Endian (0x01h est dans l'adresse la plus basse ou la moins significative). S'il s'agit de 0x00h, le système est Big-Endian.

La manière C ++ a été d'utiliser boost , où les vérifications et les transtypages du préprocesseur sont compartimentés dans des bibliothèques très testées.

La bibliothèque Predef (boost / predef.h) reconnaît quatre types différents d'endianité .

La bibliothèque Endian devait être soumise à la norme C ++ et prend en charge une grande variété d'opérations sur les données sensibles à l'endian.

Comme indiqué dans les réponses ci-dessus, l'endianité fera partie de c ++ 20.

À moins que vous n'utilisiez un framework qui a été porté sur des processeurs PPC et Intel, vous devrez effectuer des compilations conditionnelles, car les plates-formes PPC et Intel ont des architectures matérielles, des pipelines, des bus complètement différents, etc. Cela rend le code assembleur complètement différent entre les deux.

En ce qui concerne la recherche de l'endianité, procédez comme suit:

short temp = 0x1234;
char* tempChar = (char*)&temp;

Vous obtiendrez soit tempChar soit 0x12 ou 0x34, à partir duquel vous connaîtrez l'endianness.

Je ferais quelque chose comme ça:

bool isBigEndian() {
    static unsigned long x(1);
    static bool result(reinterpret_cast<unsigned char*>(&x)[0] == 0);
    return result;
}

Dans ce sens, vous obtiendriez une fonction efficace en temps qui ne fait le calcul qu'une seule fois.

Comme indiqué ci-dessus, utilisez des astuces d'union.

Cependant, il y a peu de problèmes avec ceux recommandés ci-dessus, notamment que l'accès à la mémoire non aligné est notoirement lent pour la plupart des architectures, et certains compilateurs ne reconnaissent même pas du tout ces prédicats constants, à moins que le mot ne soit aligné.

Parce qu'un simple test endian est ennuyeux, voici la fonction (modèle) qui inversera l'entrée / sortie d'un entier arbitraire selon vos spécifications, quelle que soit l'architecture de l'hôte.

#include <stdint.h>

#define BIG_ENDIAN 1
#define LITTLE_ENDIAN 0

template <typename T>
T endian(T w, uint32_t endian)
{
    // this gets optimized out into if (endian == host_endian) return w;
    union { uint64_t quad; uint32_t islittle; } t;
    t.quad = 1;
    if (t.islittle ^ endian) return w;
    T r = 0;

    // decent compilers will unroll this (gcc)
    // or even convert straight into single bswap (clang)
    for (int i = 0; i < sizeof(r); i++) {
        r <<= 8;
        r |= w & 0xff;
        w >>= 8;
    }
    return r;
};

Usage:

Pour convertir un endian donné en hôte, utilisez:

host = endian(source, endian_of_source)

Pour convertir de l'endian hôte en endian donné, utilisez:

output = endian(hostsource, endian_you_want_to_output)

Le code résultant est aussi rapide que d'écrire l'assemblage manuel sur clang, sur gcc, il est un peu plus lent (déroulé &, <<, >>, | pour chaque octet) mais toujours décent.

bool isBigEndian()
{
    static const uint16_t m_endianCheck(0x00ff);
    return ( *((uint8_t*)&m_endianCheck) == 0x0); 
}

N'utilisez pas de union!

C ++ n'autorise pas la punition de type via unions!
Lire à partir d'un champ union qui n'était pas le dernier champ écrit est un comportement indéfini !
De nombreux compilateurs prennent en charge cette fonctionnalité en tant qu'extensions, mais le langage n'offre aucune garantie.

Voir cette réponse pour plus de détails:

https://stackoverflow.com/a/11996970

Il n'y a que deux réponses valides qui sont garanties d'être portables.

La première réponse, si vous avez accès à un système qui prend en charge C ++ 20,
est d'utiliser à std::endianpartir de l'en- <type_traits>tête.

(Au moment de la rédaction de ce document, C ++ 20 n'a pas encore été publié, mais à moins que quelque chose n'affecte std::endianl'inclusion de, cela doit être le moyen préféré de tester l'endianité au moment de la compilation à partir de C ++ 20.)

À partir de C ++ 20

constexpr bool is_little_endian = (std::endian::native == std::endian::little);

Avant C ++ 20, la seule réponse valide consiste à stocker un entier, puis à inspecter son premier octet via la punition de type.
Contrairement à l'utilisation de unions, cela est expressément autorisé par le système de type C ++.

Il est également important de se rappeler que pour une portabilité optimale static_castdoit être utilisé,
car la reinterpret_castmise en œuvre est définie.

Si un programme tente d'accéder à la valeur stockée d'un objet via une valeur gl autre que l'un des types suivants, le comportement n'est pas défini: ... a charou unsigned chartype.

À partir de C ++ 11

enum class endianness
{
    little = 0,
    big = 1,
};

inline endianness get_system_endianness()
{
    const int value { 0x01 };
    const void * address = static_cast<const void *>(&value);
    const unsigned char * least_significant_address = static_cast<const unsigned char *>(address);
    return (*least_significant_address == 0x01) ? endianness::little : endianness::big;
}

C ++ 11 et suivants (sans énumération)

inline bool is_system_little_endian()
{
    const int value { 0x01 };
    const void * address = static_cast<const void *>(&value);
    const unsigned char * least_significant_address = static_cast<const unsigned char *>(address);
    return (*least_significant_address == 0x01);
}

C ++ 98 / C ++ 03

inline bool is_system_little_endian()
{
    const int value = 0x01;
    const void * address = static_cast<const void *>(&value);
    const unsigned char * least_significant_address = static_cast<const unsigned char *>(address);
    return (*least_significant_address == 0x01);
}

union {
    int i;
    char c[sizeof(int)];
} x;
x.i = 1;
if(x.c[0] == 1)
    printf("little-endian\n");
else    printf("big-endian\n");

Ceci est une autre solution. Similaire à la solution d'Andrew Hare.

non testé, mais dans mon esprit, cela devrait fonctionner? parce que ce sera 0x01 sur petit endian, et 0x00 sur gros endian?

bool runtimeIsLittleEndian(void)
{
 volatile uint16_t i=1;
 return  ((uint8_t*)&i)[0]==0x01;//0x01=little, 0x00=big
}

Déclarer:

Mon message initial est incorrectement déclaré comme "temps de compilation". Ce n'est pas le cas, c'est même impossible dans la norme C ++ actuelle. Constexpr ne signifie PAS que la fonction effectue toujours le calcul au moment de la compilation. Merci Richard Hodges pour la correction.

temps de compilation, non macro, solution constexpr C ++ 11:

union {
  uint16_t s;
  unsigned char c[2];
} constexpr static  d {1};

constexpr bool is_little_endian() {
  return d.c[0] == 1;
}

Vous pouvez également le faire via le préprocesseur en utilisant quelque chose comme le fichier d'en-tête boost qui peut être trouvé boost endian

À moins que l'en-tête endian soit uniquement GCC, il fournit des macros que vous pouvez utiliser.

#include "endian.h"
...
if (__BYTE_ORDER == __LITTLE_ENDIAN) { ... }
else if (__BYTE_ORDER == __BIG_ENDIAN) { ... }
else { throw std::runtime_error("Sorry, this version does not support PDP Endian!");
...

Si vous ne voulez pas de compilation conditionnelle, vous pouvez simplement écrire du code indépendant endian. Voici un exemple (tiré de Rob Pike ):

Lecture d'un entier stocké en little-endian sur le disque, d'une manière indépendante de l'endian:

i = (data[0]<<0) | (data[1]<<8) | (data[2]<<16) | (data[3]<<24);

Le même code, en essayant de prendre en compte l'endianité de la machine:

i = *((int*)data);
#ifdef BIG_ENDIAN
/* swap the bytes */
i = ((i&0xFF)<<24) | (((i>>8)&0xFF)<<16) | (((i>>16)&0xFF)<<8) | (((i>>24)&0xFF)<<0);
#endif

int i=1;
char *c=(char*)&i;
bool littleendian=c;

Que dis-tu de ça?

#include <cstdio>

int main()
{
    unsigned int n = 1;
    char *p = 0;

    p = (char*)&n;
    if (*p == 1)
        std::printf("Little Endian\n");
    else 
        if (*(p + sizeof(int) - 1) == 1)
            std::printf("Big Endian\n");
        else
            std::printf("What the crap?\n");
    return 0;
}

Voici une autre version C. Il définit une macro appelée wicked_cast()pour le découpage de type en ligne via les littéraux d'union C99 et l' __typeof__opérateur non standard .

#include <limits.h>

#if UCHAR_MAX == UINT_MAX
#error endianness irrelevant as sizeof(int) == 1
#endif

#define wicked_cast(TYPE, VALUE) \
    (((union { __typeof__(VALUE) src; TYPE dest; }){ .src = VALUE }).dest)

_Bool is_little_endian(void)
{
    return wicked_cast(unsigned char, 1u);
}

Si les entiers sont des valeurs à un octet, l'endianité n'a aucun sens et une erreur de compilation sera générée.

La façon dont les compilateurs C (au moins tous ceux que je connais) fonctionnent, l'endianité doit être décidée au moment de la compilation. Même pour les processeurs biendiens (comme ARM och MIPS), vous devez choisir l'endianité au moment de la compilation. De plus, l'endianité est définie dans tous les formats de fichiers courants pour les exécutables (tels que ELF). Bien qu'il soit possible de créer un blob binaire de code biandien (pour certains exploits de serveur ARM peut-être?), Cela doit probablement être fait en assembleur.

Comme l'a souligné Coriiander, la plupart (sinon la totalité) de ces codes seront optimisés lors de la compilation, de sorte que les binaires générés ne vérifieront pas "l'endianité" au moment de l'exécution.

Il a été observé qu'un exécutable donné ne devrait pas s'exécuter dans deux ordres d'octets différents, mais je n'ai aucune idée si c'est toujours le cas, et cela semble être un hack pour moi de vérifier au moment de la compilation. J'ai donc codé cette fonction:

#include <stdint.h>

int* _BE = 0;

int is_big_endian() {
    if (_BE == 0) {
        uint16_t* teste = (uint16_t*)malloc(4);
        *teste = (*teste & 0x01FE) | 0x0100;
        uint8_t teste2 = ((uint8_t*) teste)[0];
        free(teste);
        _BE = (int*)malloc(sizeof(int));
        *_BE = (0x01 == teste2);
    }
    return *_BE;
}

MinGW n'a pas pu optimiser ce code, même s'il optimise les autres codes ici même. Je crois que c'est parce que je laisse la valeur "aléatoire" qui a été affectée à la mémoire d'octets plus petite telle qu'elle était (au moins 7 de ses bits), donc le compilateur ne peut pas savoir quelle est cette valeur aléatoire et il n'optimise pas la fonction loin.

J'ai également codé la fonction afin que la vérification ne soit effectuée qu'une seule fois et que la valeur de retour soit stockée pour les tests suivants.

bien qu'il n'y ait pas de moyen rapide et standard de le déterminer, cela le produira:

#include <stdio.h> 
int main()  
{ 
   unsigned int i = 1; 
   char *c = (char*)&i; 
   if (*c)     
       printf("Little endian"); 
   else
       printf("Big endian"); 
   getchar(); 
   return 0; 
} 

Voir l' illustration Endianness - C-Level Code.

// assuming target architecture is 32-bit = 4-Bytes
enum ENDIANNESS{ LITTLEENDIAN , BIGENDIAN , UNHANDLE };


ENDIANNESS CheckArchEndianalityV1( void )
{
    int Endian = 0x00000001; // assuming target architecture is 32-bit    

    // as Endian = 0x00000001 so MSB (Most Significant Byte) = 0x00 and LSB (Least     Significant Byte) = 0x01
    // casting down to a single byte value LSB discarding higher bytes    

    return (*(char *) &Endian == 0x01) ? LITTLEENDIAN : BIGENDIAN;
} 

Je parcourais le manuel: Système informatique: le point de vue d'un programmeur , et il y a un problème pour déterminer quel endian est-ce par le programme C.

J'ai utilisé la fonctionnalité du pointeur pour le faire comme suit:

#include <stdio.h>

int main(void){
    int i=1;
    unsigned char* ii = &i;

    printf("This computer is %s endian.\n", ((ii[0]==1) ? "little" : "big"));
    return 0;
}

Comme l' int prend 4 octets et que char ne prend que 1 octet. Nous pourrions utiliser un pointeur char pour pointer vers l' int avec la valeur 1. Ainsi , si l'ordinateur est peu endian, l' omble chevalier que pointeur char pointe est à la valeur 1, sinon, sa valeur doit être 0.