Discussion :

[Antoine_935]

Salut à toutes et à tous

Mon très cher compilateur me met aujourd'hui au défi:
Je voudrais créer une union capable de tenir tous types de valeurs numériques: 1, 2, 4 ou 8 bytes;

Rien de très compliqué jusque là, une simple union suffit:

Code :

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

1
2
3
4
5
6
typedef union {
    int8_t b;
    int16_t s;
    int32_t i;
    int64_t l;
} cvalue;

Je voudrais ensuite pouvoir facilement additionner des "cvalue" de tous types... un byte avec un int, un short avec un long...

Seulement, sur mon architecture intel (little endian donc si je ne m'abuse... corrigez moi), c'est infaisable de cette manière:

Code :

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

1
2
3
4
5
6
7
v1.b = 1;
v2.l = 1;
 
int64_t result = v1.l + v2.l;
printf("Resultat: %li\n", result);
 
// Résultat: 2686722

Si je pouvais mettre ces valeurs en big endian et les additionner en mode big endian, ça résoudrait le souci... mais je ne pense pas que ce soit possible, ou même performant.

Donc si je comprends bien, mon problème, précisément, est le suivant:
Dans mon union, les membres sont alignés sur le début:

Code :

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

1
2
3
4
5
6
7
8
Une cvalue prend 8 bytes:
|  |  |  |  |  |  |  |  |
 
Un int8_t prend le premier byte, les autres sont sensé être à zero
| 1| 0| 0| 0| 0| 0| 0| 0|
 
Un int64_t prend tous les bytes
| 0| 0| 0| 0| 0| 0| 0| 1|

Du coup, l'addition foire.

Je pense actuellement à adapter mon union avec des structures pour mettre du padding, comme ça les variables sont alignées, mais... oui, vous le voyez vous mêmes, ce n'est pas très propre.

Quelqu'un aurait-il une meilleure idée ? Quelque chose qui fontionne aussi avec les soustractions, divisions et multiplications ?


Edit: oh, dernière petite question: y a-t-il un moyen de savoir lors de la compilation si on est en little ou big endian ? style une constante du précompilateur ?

[diogene]

Je ne vois pas ce que vient faire la question de l'endian dans cette affaire.
On peut parfaitement écrire

Code :

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

1
2
3
int64_t result = v1.l + v2.l;
//ou encore, je suppose que c'est plutôt ce que tu voulais écrire
int64_t result = v1.b + v2.l;

La seule question qui se pose c'est que v1.b et v2.l doivent bien contenir un int8_t et un int64_t
Normalement, pour pouvoir lire correctement la valeur sous la forme v1.l , il faut qu'auparavant on ait v1.l = .... et non quelque chose comme v1.s = .... . Et ce n'est pas lié à l'endian.
Norme :

6.5.2.3 Structure and union members
....
82) If the member used to access the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called "type punning"). This might be a trap representation.

Un int8_t prend le premier byte, les autres sont sensé être à zero

Qui garantit cela ?
Norme :

6.2.6.1 General
...
7 When a value is stored in a member of an object of union type, the bytes of the object representation that do not correspond to that member but do correspond to other members take unspecified values

[Antoine_935]

Je ne vois pas ce que vient faire la question de l'endian dans cette affaire.

Parce qu'en big endian ce problème ne se poserait même pas.

On peut parfaitement écrire

Code :

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

1
2
3
int64_t result = v1.l + v2.l;
//ou encore, je suppose que c'est plutôt ce que tu voulais écrire
int64_t result = v1.b + v2.l;

Non, c'est bel et bien la première instruction que je veux écrire et faire fonctionner.

Normalement, pour pouvoir lire correctement la valeur sous la forme v1.l , il faut qu'auparavant on ait v1.l = .... et non quelque chose comme v1.s = .... . Et ce n'est pas lié à l'endian.

Si, justement. Essaye de refaire le schéma avec le big endian, et tout fonctionne bien.

Qui garantit cela ?

Mon programme garanti celà.


Ce que je cherche, c'est justement de pouvoir faire des additions de manière simple, quel que soit le contenu de mes deux unions.

[gl]

Parce qu'en big endian ce problème ne se poserait même pas.

D'une manière générale, si le problème se pose également.
Vu de la norme, écrire dans une des champs de l'union (b ici) et lire ensuite un autre champ (l ici) n'est pas correct [1].

Cela peut fonctionner sur certaines architectures mais ce n'est pas garanti par la norme C et donc pas portable

Si, justement. Essaye de refaire le schéma avec le big endian, et tout fonctionne bien.

Voir réponse précédente. Ce n'est pas garanti par la norme.

Mon programme garanti celà.

La norme ne le garanti pas. Donc, sauf cas particulier bien précis, ce n'est pas correct.


Bref, ce que tu cherches à coder peut fonctionner dans certains environnements mais n'est pas portable.

Ceci étant, en oubliant pour l'instant l'utilisation d'union ou tout autre choix d'implémentation technique, que cherches-tu à faire précisément ?




[1] Je laisse volontairement de côté les exceptions qui ne concernent pas du tout le cas présent.

[Antoine_935]

Cela peut fonctionner sur certaines architectures mais ce n'est pas garanti par la norme C et donc pas portable

Bon, dommage, la solution sonnait plutôt pas mal.

Ceci étant, en oubliant pour l'instant l'utilisation d'union ou tout autre choix d'implémentation technique, que cherches-tu à faire précisément ?

Je cherche à faire une machine virtuelle. Non pas pour un os mais pour un langage interprété. C'est dans ce cadre que j'avais besoin de pouvoir additionner plusieurs types numériques entre eux sans me soucier de savoir ce qu'ils étaient réellement.

Mais après un peu plus de recherches, je me suis rendu compte que j'opérais à trop haut niveau. C'est à dire que mon bytecode décrivait des opérations trop complexes. En redescendant plus bas, ce problème ne se pose même plus, je suis bel et bien obligé de faire mes conversions plus convenablement.


Merci à vous deux pour les précisions sur ces normes

[Mac LAK]

Edit: oh, dernière petite question: y a-t-il un moyen de savoir lors de la compilation si on est en little ou big endian ? style une constante du précompilateur ?

Usuellement, non. Après, ça se teste facilement :

Code :

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

1
2
3
4
5
int IsBigEndian ( void ) {
  int test = 0x11223344 ;
  char* p = (char*)(&test) ;
  return ((*p)==0x11) ;
}

Renvoie non-zéro si la plate-forme est en big-endian.

[nicolas.sitbon]

Usuellement, non. Après, ça se teste facilement :

Code :

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

1
2
3
4
5
int IsBigEndian ( void ) {
  int test = 0x11223344 ;
  char* p = (char*)(&test) ;
  return ((*p)==0x11) ;
}

Renvoie non-zéro si la plate-forme est en big-endian.

Ce code ne fonctionnera que sur des architectures ou un char fait 8 bits (et accessoirement ou int fait 32 bits (sans padding).
On peut empêcher un comportement ératique en modifiant le type de p

Code :

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

1
2
3
4
5
6
int IsBigEndian(void) 
{
   uint32_t test = 0x11223344;
   uint8_t const * p = (uint8_t *) &test;
   return  (*p) == 0x11;
}

L'avantage, est que si ces types ne sont pas définis, on peut les réajuster avant de re-compiler suivant l'architecture sans craindre que la fonction ne retourne un résultat erroné.

[Mac LAK]

Ce code ne fonctionnera que sur des architectures ou un char fait 8 bits (et accessoirement ou int fait 32 bits (sans padding).

Sur ce genre de plate-forme (habituellement, c'est de l'embarqué ou du "dinosaure", ça devient de plus en plus rare), il est plus courant d'utiliser un système d'abstraction qui va, entre autres, définir des macros d'endianness.
Si la cible est suffisamment "puissante" pour supporter une librairie d'abstraction complète (ACE, POCO), on utilise alors l'API d'abstraction directement. Sinon, ça se règle en général via un header gavé de compilation conditionnelle qui finit par assurer la définition d'une des deux macros "BIG_ENDIAN" / "LITTLE_ENDIAN".
On peut trouver un tel header à cette adresse, par exemple, le seul souci étant qu'il marche rarement pour les cibles réellement exotiques (ex : cœur PPC embarqué dans un FPGA).

L'avantage, est que si ces types ne sont pas définis, on peut les réajuster avant de re-compiler suivant l'architecture sans craindre que la fonction ne retourne un résultat erroné.

D'un autre côté, un problème d'endianness se voit immédiatement, dès le premier test unitaire... Test que tout développeur est censé faire.

Quitte à devoir définir quelque chose pour faire compiler le code, autant passer directement une des deux macros d'endianness à la compilation, ça évite d'avoir à appeler du code...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
#ifdef BIG_ENDIAN
  #ifdef LITTLE_ENDIAN
    #error Must not define BIG_ENDIAN *AND* LITTLE_ENDIAN.
  #else
    // OK.
  #endif
#else
  #ifdef LITTLE_ENDIAN
    // OK.
  #else
    #error Must define BIG_ENDIAN or LITTLE_ENDIAN.
  #endif
#endif

[Médinoc]

Le problème, c'est que je ne connais aucun moyen de vérifier à la compilation que ces macros ne sont pas incorrectement définies.

[Mac LAK]

Le problème, c'est que je ne connais aucun moyen de vérifier à la compilation que ces macros ne sont pas incorrectement définies.

Moi non plus, c'est réellement un problème de test unitaire de portage / non-régression...

En général, quand j'ai un truc de ce genre, je fais un petit programme de test très basique qui va tester des éléments comme :

• Taille des structures après compilation (par rapport à une taille attendue).
• Distance (en octets) entre les différents champs des structures en question.
• Taille des mots-machine et des différents types de base.
• Vérification de l'endianness (ntoh* et hton* peuvent permettre de vérifier ça).
• Vérification des algos de base du système (ceux rajoutés pour les besoins du projet).
• Etc.

Ainsi, le lancement de ce petit test me sert de TU de portage, et en plus de test rapide de non-régression lors d'ajout de fonctionnalités.

[Antoine_935]

Merci pour ces réponses supplémentaires
Je garderai précieusement ce petit header pour les macros. Je ne pense pas être confronté bientôt à des systèmes aussi étranges que celui que tu décris, donc je peux sans doute utiliser ce header de manière assez sure

[Mac LAK]

donc je peux sans doute utiliser ce header de manière assez sure

Si tu ne bosses qu'avec des machines "classiques" (PC x86 sous Windows/Linux ou Mac), t'es certain d'être tranquille avec. Sinon, il peut y avoir des failles, mais le petit bout de #ifdef que j'ai mis un peu plus haut te permettra de toujours "blinder" en t'assurant qu'une seule et unique macro d'endianness est définie.