Discussion :

[Kromagg]

Bonjour à tous

En parcourant le code du moteur OpenSceneGraph, je suis tombé sur la fonction permettant de détecter l'endianness de la machine, en voici une version légèrement modifiée

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
const char* getCpuByteOrder()
{
    union 
    {
        char big_endian_1[2];
        short is_it_really_1;
    } u;
    u.big_endian_1[0] = 0;
    u.big_endian_1[1] = 1;
 
    printf("%i\n", u.is_it_really_1);
 
    if (u.is_it_really_1 == 1)
        return "bigEngian";
    else 
        return "littleEndian";
}

Sur ma machine u.is_it_really_1 vaut 256 alors qu'il n'a pas été initialisé. Je ne vois pas non plus l'intérêt d'utiliser big_endian_1 (de plus c'est un tableau).
Comment fonctionne cette fonction ? Le type des variables est-il important ? Pourquoi utiliser une union ?

Kromagg

[Pouet_forever]

Le char vaut 1 octet, et le short vaut 2 octets.
Le fait d'utiliser l'union fait que modifier la valeur de big_endian_1 modifiera aussi la valeur de is_it_really_1 car ils utiliseront le même espace mémoire.

Du coup si on fait comme ton code en mémoire on aura ça :

00000000 00000001 -> Big endian
00000001 00000000 -> Little endian

Donc si on utilise un short, comme il utilise la même partie de mémoire, on aura 1 en big endian et 256 en little endian.

[Sve@r]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
const char* getCpuByteOrder()
{
    union 
    {
        char big_endian_1[2];
        short is_it_really_1;
    } u;
    u.big_endian_1[0] = 0;
    u.big_endian_1[1] = 1;
 
    printf("%i\n", u.is_it_really_1);
 
    if (u.is_it_really_1 == 1)
        return "bigEngian";
    else 
        return "littleEndian";
}

Bizarre. Moi j'aurais plutôt affecté 1 dans u.is_it_really_1 puis serais allé tester big_endian_1[1]. Une seule affectation au lieu de 2...

[Kromagg]

Merci Pouet_forever, c'est beaucoup plus clair

Mais est-ce portable comme solution, est-ce que les types char et short sont codés sur le même nombre d'octets quelque soit l'OS, oy est-ce que cela dépend entièrement de l'architecture matériel ?

Kromagg

[diogene]

Par définition, char est codé sur un byte. On n'a pas de garantie sur la taille d'un short.
Mais on peut en tenir compte :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
const char* getCpuByteOrder()
{
    union
    {
        char big_endian_1[sizeof (short)];
        short is_it_really_1;
    } u;
    u.is_it_really_1 = 1;
    return u.big_endian_1[0]==1 ? "littleEndian" : "bigEngian";
}

[gl]

Mais est-ce portable comme solution, est-ce que les types char et short sont codés sur le même nombre d'octets quelque soit l'OS, oy est-ce que cela dépend entièrement de l'architecture matériel ?

Non ce n'est pas garantie être portable :

• A cause de la taille variable des types d'une plateforme à l'autre (point que le code fourni par diogene résous)
• Car vu de la norme, dans une union, seule la lecture du dernier élément écrit est correct [1] (en clair après avoir écris is_it_really_1 la norme ne garantie pas que tu puisse lire big_endian_1).

En pratique, sur les plateformes courantes (et moyennant la correction de diogene) tu ne devrais pas rencontrer de problème particulier.



[1] Je laisse volontairement ici les cas particuliers qui ne nous concerne pas.

[Médinoc]

À votre place, j'utiliserais le type entier le plus grand possible (genre long ou long long), de peur de tomber sur une implémentation où sizeof(char)==sizeof(short) mais où les autres types entiers seraient plus grands.

[Sve@r]

À votre place, j'utiliserais le type entier le plus grand possible (genre long ou long long), de peur de tomber sur une implémentation où sizeof(char)==sizeof(short) mais où les autres types entiers seraient plus grands.

J'ai une fois travaillé sur un ordinateur Siemens/Nixdorf sur lequel le short valait 2, le int valait 4 et le long 6. Au début mes codes ne marchaient pas bien et je galérais. Rhaa la tronche que j'ai faite quand j'ai découvert cte merde !!!

[Kromagg]

Dans ce cas y a-t-il un moyen correcte de détecter l'endianness d'une architecture ?

Kromagg

[Médinoc]

Comme je te dis: Le type le plus petit contre le type le plus grand.

Si les deux sont de taille égale, alors tu n'auras pas de problèmes d'endianness de toute façon.

[nicolas.sitbon]

Par définition, char est codé sur un byte. On n'a pas de garantie sur la taille d'un short.
Mais on peut en tenir compte :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
const char* getCpuByteOrder()
{
    union
    {
        char big_endian_1[sizeof (short)];
        short is_it_really_1;
    } u;
    u.is_it_really_1 = 1;
    return u.big_endian_1[0]==1 ? "littleEndian" : "bigEngian";
}

Le problème de cette méthode et tu le sais diogene, c'est qu'elle invoque un comportement indéterminé.
On peut contourner le problème (6.3.2.2.7) ainsi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
const char * getCpuByteOrder(void)
{
   short is_it_really_1 = 1;
   return *(unsigned char*)&is_it_really_1 == 1U ? "littleEndian" : "bigEngian";
}

L'ennui c'est qu'on ne détecte pas les endianness exotique stype middle endian (PDP-11).
Cordialement.