Salut,

J'ai une question vraiment débile, qui me fait douter

En gros j'ai un tableau de uint8_t.
J'ai une doc qui décrit l'ordre d'informations présent dans ce buffer, via le nombre de bits. Sachant que ces valeurs peuvent être à cheval sur plusieurs "cases" car la structure n'est pas alignée, enfin bref...
Par exemple j'ai :

Identifiant 5bits
Valide 1bits
Valeur 6bits
Bourrage 4bits

Et là où je m'embrouille c'est dans "l'ordre" de ces bits, car on est d'accord qu'en little endian c'est de gauche à droite
Donc par exemple pour l'exemple ci-dessus, pour:

Identifiant = 3
Valide = 1
Valeur = 7
Bourrage = 1
j'aurais sur 2 octets en représentation binaire
t[0] = 11110 0011
t[1] = 0000 1000

Avec identifiant, valide, valeur, bourrage

J'ai bon ?
J'avoue que j'ai honte de me poser la question, mais ayant fait pas mal de bricolage sur tout ces trucs dernièrement, j'ai perdu un peu la boule, et j'ai peur de me gourrer

Quand tu parles de structures de bit, big endian et little endian ne veut pas dire grand chose en terme des "cinq premier bits". meme en C quand tu fais une structure de bits:

struct something {
  int identifiant:5;
  int valide:1;
  int valeur:6;
  int bourrage:4;
};

L'ordre des champs depend du compilateur.

en general, tu as une implementation de reference pour verifier si tu interprete ca correctement.

l'endianess c'est l'ordre des octets dans la représentation d'un entier de plusieurs octets, et non pas l'ordre des bits dans un octet comme t'as l'air de croire. Par conséquent ça n'a pas vraiment de pertinence pour les structures de bits.

dans ton cas de figure les trois premiers bits sont l'identifiant, le suivant c'est "valide", ensuite c'est la valeur puis le bourrage

Le 19 janvier 2022 à 05:18:26 :
l'endianess c'est l'ordre des octets dans la représentation d'un entier de plusieurs octets, et non pas l'ordre des bits dans un octet comme t'as l'air de croire. Par conséquent ça n'a pas vraiment de pertinence pour les structures de bits.

dans ton cas de figure les trois premiers bits sont l'identifiant, le suivant c'est "valide", ensuite c'est la valeur puis le bourrage

Certes mais l'endianness suggère quand même un ordre des bits
"Dans une architecture gros-boutiste, les bits sont conventionnellement numérotés de la gauche vers la droite. Ainsi le bit de poids le plus fort est le bit 0, et le bit de poids le plus faible est le 7 dans un octet. Dans une architecture petit-boutiste, c'est le contraire.

Si l'octet doit représenter un nombre entier, alors la convention gros-boutiste peut porter à confusion car le poids du bit n est alors 27-n (au lieu de 2n avec la convention petit-boutiste). En revanche, elle convient mieux pour représenter une fraction binaire, le poids du bit n étant alors 2-n (contre 2n-7 pour petit-boutiste). "
https://fr.wikipedia.org/g/wiki/Boutisme#Ordre_des_bits

C'est juste qu'il est assez flou de dire les "5 premiers bits" qui sont en faite les 5 premiers bits en partant de la droite

Le 19 janvier 2022 à 02:34:27 :
Quand tu parles de structures de bit, big endian et little endian ne veut pas dire grand chose en terme des "cinq premier bits". meme en C quand tu fais une structure de bits:

struct something {
  int identifiant:5;
  int valide:1;
  int valeur:6;
  int bourrage:4;
};

L'ordre des champs depend du compilateur.

en general, tu as une implementation de reference pour verifier si tu interprete ca correctement.

Malheureusement j'ai pas d’implémentation sur laquelle me baser

Le 19 janvier 2022 à 13:23:14 :

Le 19 janvier 2022 à 05:18:26 :
l'endianess c'est l'ordre des octets dans la représentation d'un entier de plusieurs octets, et non pas l'ordre des bits dans un octet comme t'as l'air de croire. Par conséquent ça n'a pas vraiment de pertinence pour les structures de bits.

dans ton cas de figure les trois premiers bits sont l'identifiant, le suivant c'est "valide", ensuite c'est la valeur puis le bourrage

Certes mais l'endianness suggère quand même un ordre des bits
"Dans une architecture gros-boutiste, les bits sont conventionnellement numérotés de la gauche vers la droite. Ainsi le bit de poids le plus fort est le bit 0, et le bit de poids le plus faible est le 7 dans un octet. Dans une architecture petit-boutiste, c'est le contraire.

Si l'octet doit représenter un nombre entier, alors la convention gros-boutiste peut porter à confusion car le poids du bit n est alors 27-n (au lieu de 2n avec la convention petit-boutiste). En revanche, elle convient mieux pour représenter une fraction binaire, le poids du bit n étant alors 2-n (contre 2n-7 pour petit-boutiste). "
https://fr.wikipedia.org/g/wiki/Boutisme#Ordre_des_bits

C'est juste qu'il est assez flou de dire les "5 premiers bits" qui sont en faite les 5 premiers bits en partant de la droite

Le 19 janvier 2022 à 02:34:27 :
Quand tu parles de structures de bit, big endian et little endian ne veut pas dire grand chose en terme des "cinq premier bits". meme en C quand tu fais une structure de bits:

struct something {
  int identifiant:5;
  int valide:1;
  int valeur:6;
  int bourrage:4;
};

L'ordre des champs depend du compilateur.

en general, tu as une implementation de reference pour verifier si tu interprete ca correctement.

Malheureusement j'ai pas d’implémentation sur laquelle me baser

Mais on l’occurrence on s'en fiche un peu des conventions de notation, vraiment l'endianess c'est quelque chose de propre aux nombres. "L'ordre" de tes bits dans l'octet, c'est les bits de poids faible vers les bits de poids fort, et l'ordre des octets c'est l'ordre canonique donné par le buffer.

identifiant = buffer[0] & 0b00011111
valide = (buffer[0] & 0b00100000) >> 5
valeur = ((buffer[0] & 0b11000000) >> 6) | ((buffer[1] & 0b00001111) << 2)
bourrage = (buffer[1] & 0b11110000) >> 4

Eli, sauf que c'est absolument pas une convention que le premier bit est le bit de poids faible. IP par exemple est spécifié avec le bit 0 est le bit de poids fort.
Une spec complète devrait indiquer l'ordre des bits dans un octet. D'ailleurs IP ne spécifié pas par octet mais par mot de 32 bit.

Reglegraduee, si tu n'as pas d'implémentation de référence, peut être tu as un fichier encodé correctement ou un outils qui utilise ce format pour tester?

Le 19 janvier 2022 à 17:14:59 :
Eli, sauf que c'est absolument pas une convention que le premier bit est le bit de poids faible. IP par exemple est spécifié avec le bit 0 est le bit de poids fort.
Une spec complète devrait indiquer l'ordre des bits dans un octet. D'ailleurs IP ne spécifié pas par octet mais par mot de 32 bit.

Reglegraduee, si tu n'as pas d'implémentation de référence, peut être tu as un fichier encodé correctement ou un outils qui utilise ce format pour tester?

Tu veux dire que dans un packet ip comme spécifié ici:
https://fr.wikipedia.org/rg/wiki/IPv4#En-t%C3%AAte_IPv4

la version de l'ip c'est buffer[0] & 0xf0 , et la longueur de l'entête c'est buffer[0] & 0x0f ?

Oui. (Sauf que c'est 32 bit, mais oui.) Regarde la version anglaise:
https://en.wikipedia.org/wiki/IPv4#Header
"The fields in the header are packed with the most significant byte first (big endian), and for the diagram and discussion, the most significant bits are considered to come first (MSB 0 bit numbering). The most significant bit is numbered 0"

Le 20 janvier 2022 à 02:06:53 :
Oui. (Sauf que c'est 32 bit, mais oui.) Regarde la version anglaise:

même si c'était pas marqué je considérais les éléments du buffer comme étant des octets et vu qu'on est en big endian ça correspond bien à l'octet de poids fort, donc normalement c'est bien ça

https://en.wikipedia.org/wiki/IPv4#Header
"The fields in the header are packed with the most significant byte first (big endian), and for the diagram and discussion, the most significant bits are considered to come first (MSB 0 bit numbering). The most significant bit is numbered 0"

Ouais en effet, bien vu