Adresse/offset du champs d'une structure

Version imprimable

Bonjour,

J'ai une structure avec des champs de differentes tailles. J'aimerais déclarer des 'defines' définissant l'offset de chacun des champs. Concrètement :
Code:

1 2 3 4 5 6 7 8 9 10 typedef struct { tModbusFrame RequestBuf; bool FrameReceived; tModbusStatus ModbusStatus; byte NbReceiveErrors; } tModbusPort; #define MODBUS_STATUS_OFFSET sizeof( tModbusFrame ) + sizeof( bool ) #define NB_ERRORS_OFFSET MODBUS_STATUS_OFFSET + sizeof( tModbusStatus)
Le but des sizeof est de rendre les offsets independant de la cible (exemple, bool = 8 bits sur µcontrolleur, 16 bits sur pc).

Quelqu'un aurait-il quelque chose de plus simple pour faire mes define (car ma vraie structure a une trentaine de champs...) ?

Merci à tous.

Ludo

23/01/2007, 14h47
hegros

Par curiosité ca te sert a quoi ? Parce que pour accéder un membre on fait MaGrosseStruct.champs1
23/01/2007, 14h53
ludo894

En fait, la variable de type cette structure est locale à un fichier toto. J'accède aux champs depuis un fichier titi via des fonctions Read ou Write, prenant comme paramètre l'offset d'ecriture/lecture. Est-ce clair ?

Voici comment je pratique:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 #include <stdio.h> #include <stdlib.h> #define OFFSET_OF(type, membre) ((size_t) &((type *)0)->membre) struct Essai { int x; int y; int z; }; int main(void) { size_t offset = OFFSET_OF(struct Essai, y); printf("L'offset de z est %u bytes!", offset); return EXIT_SUCCESS; }
Ton implantation de MODBUS_STATUS_OFFSET par exemple n'est pas portable, car ne tient pas compte des éventuelles contraintes d'alignement. Ex:
Code:

1 2 3 4 5 struct Essai { int x; char c; int y; };
Sur ma machine, l'offset de y n'est pas de 5 bytes, mais de 8 bytes à cause de l'alignegnement des variables de type int sur des adresses multiples de 4.

Thierry

23/01/2007, 15h25
JeitEmgie

vérifiez sur votre plate-forme si stddef.h définit offsetof(s,m) et/ou __offsetof(s,m)

notez qu'en pratiquant de la sorte, si vous rendez votre code source compatible multi-environnement , les fichiers générés eux ne le seront pas…
23/01/2007, 15h32
Thierry Chappuis

Citation:

Envoyé par ludo894

En fait, la variable de type cette structure est locale à un fichier toto. J'accède aux champs depuis un fichier titi via des fonctions Read ou Write, prenant comme paramètre l'offset d'ecriture/lecture. Est-ce clair ?

La sauvegarde d'une structure dans un fichier binaire est un problème délicat. As-tu un pouvoir de décision sur le format du fichier à utiliser pour stocker ta structure? Si tel est le cas, cet article est pour toi http://emmanuel-delahaye.developpez....m#enreg_struct

Personnellement, j'aurais tendance à enregistrer une structure dans un fichier texte au format CSV (comma separated value), voir XML..

Thierry

Bonjour,

G_STRUCT_OFFSET :mrgreen:

Code:

1
2
#define G_STRUCT_OFFSET(struct_type, member)	\
    ((glong) ((guint8*) &((struct_type*) 0)->member))

23/01/2007, 16h09
ludo894

Ta solution est interressante Thierry

Code:

#define OFFSET_OF(type, membre) ((size_t) &((type *)0)->membre)

Le problème est que le calcul de l'offset se fait dynamiquement : j'aurais préféré un 'calcul' statique...

Bien vu pour le probleme d'alignement : je viens justement d'avoir le bug !
Ma structure est forcemment déclarée dans un .h.
23/01/2007, 16h24
Thierry Chappuis

Citation:

Envoyé par ludo894

Ta solution est interressante Thierry

Code:

#define OFFSET_OF(type, membre) ((size_t) &((type *)0)->membre)

Le problème est que le calcul de l'offset se fait dynamiquement : j'aurais préféré un 'calcul' statique...

Bien vu pour le probleme d'alignement : je viens justement d'avoir le bug !
Ma structure est forcemment déclarée dans un .h.

C'est pas dynamique, l'offset est calculé à la compilation. La solution de la glib proposée par gege est probablement encore plus portable. Je persiste à dire que ce n'est pas une bonne idée de vouloir sauver ta structure dans un fichier comme tu le fais.

Thierry
23/01/2007, 16h38
Jean-Marc.Bourguet

Pourquoi chercher a definir une macro qui existe deja dans stddef.h et qui s'appelle alors offsetof?

Sinon, les IO binaires se basant sur l'interpretation d'une structure C, on sait ce que ca donne: des bugs quand on change de flags de compilation, de version de compilateur, d'architecture ou d'OS.
23/01/2007, 16h48
ludo894

Oups, j'y suis allé un peu vite : effectivement c'est un 'calcul statique'...
Pourquoi est-ce une si mauvaise idée de sauver ma structure dans un fichier ?
23/01/2007, 16h48
Thierry Chappuis

Citation:

Envoyé par Jean-Marc.Bourguet

Pourquoi chercher a definir une macro qui existe deja dans stdlib.h et qui s'appelle alors offsetof?

Simplement parce que je l'ignorais! Merci pour le renseignement

EDIT: c'est standard? C99?

Thierry
23/01/2007, 16h52
ludo894

Citation:

Envoyé par Jean-Marc.Bourguet

Pourquoi chercher a definir une macro qui existe deja dans stdlib.h et qui s'appelle alors offsetof?

Perso cette macro n'est pas définie dans mon stdlib.h !
23/01/2007, 16h56
Thierry Chappuis

Citation:

Envoyé par ludo894

Oups, j'y suis allé un peu vite : effectivement c'est un 'calcul statique'...
Pourquoi est-ce une si mauvaise idée de sauver ma structure dans un fichier ?

En vrac:
1) La représentation interne des données en C n'est pas fixée par la norme et peut varier d'une architecture à l'autre. La norme se contente de spécifier les valeurs extrêmes que doivent être capables de stocker chacuns des types.
2) Les contraintes d'alignement
3) L'endianesse (ça se dit ça). Sur certaines architectures, les données sont codées avec le byte de poids faible à une adresse inférieur à celle du byte de poids fort (little endian), et sur d'autres, c'est le contraire (big endian).

Thierry
23/01/2007, 17h06
Jean-Marc.Bourguet

Citation:

Envoyé par ludo894

Perso cette macro n'est pas définie dans mon stdlib.h !

Desole, c'est dans stddef.h. (je corrige le message initial).
23/01/2007, 17h08
Jean-Marc.Bourguet

Citation:

Envoyé par mujigka

EDIT: c'est standard? C99?

C90, mais dans stddef.h et pas stdlib.h.
23/01/2007, 17h15
Thierry Chappuis

Citation:

Envoyé par Jean-Marc.Bourguet

Desole, c'est dans stddef.h. (je corrige le message initial).

Verifié! Et en c'était disponible depuis C90... :scarymov:

Il faut dire que je ne sers pas souvant de cette macro...

Thierry
23/01/2007, 18h04
Emmanuel Delahaye

Citation:

Envoyé par ludo894

J'ai une structure avec des champs de differentes tailles. J'aimerais déclarer des 'defines' définissant l'offset de chacun des champs. Concrètement :

C'est pas possible. Il faut utiliser une structure 'en dur', c'est à dire un tableau de unsigned char. C'est la seule façon d'être portable (indépendant de l'architecture). Les structures, c'est pour les données internes. Pas pour les interfaces physiques (flux).

On peut automatiser ça à coup de macros. Faut maitriser...
23/01/2007, 18h07
Emmanuel Delahaye

Citation:

Envoyé par ludo894

Ta solution est interressante Thierry

Code:

#define OFFSET_OF(type, membre) ((size_t) &((type *)0)->membre)

Le problème est que le calcul de l'offset se fait dynamiquement : j'aurais préféré un 'calcul' statique...

Bien vu pour le probleme d'alignement : je viens justement d'avoir le bug !
Ma structure est forcemment déclarée dans un .h.

C'est du statique. Et c'est en fait la macro offsetof() qui est dans <stddef.h>

Mais ça ne résout rien, ton code n'est pas portable.

Je t'ai déjà donné une solution (enfin, le début)...
23/01/2007, 18h52
Thierry Chappuis

Citation:

Envoyé par Emmanuel Delahaye

C'est pas possible. Il faut utiliser une structure 'en dur', c'est à dire un tableau de unsigned char. C'est la seule façon d'être portable (indépendant de l'architecture). Les structures, c'est pour les données internes. Pas pour les interfaces physiques (flux).

On peut automatiser ça à coup de macros. Faut maitriser...

La solution binaire (TLV ou XDR: http://emmanuel-delahaye.developpez....m#enreg_struct ) est-elle de manière générale à préférer à un fichier texte (du type CSV ou autre)? Le problème de l'encodage (ASCII) est-il une limitation importante d'un point de vue de la portabilité?

Salutations

Thierry
23/01/2007, 19h49
Emmanuel Delahaye

Citation:

Envoyé par mujigka

La solution binaire (TLV ou XDR: http://emmanuel-delahaye.developpez....m#enreg_struct ) est-elle de manière générale à préférer à un fichier texte (du type CSV ou autre)?

Ca dépend des contraintes. Si on est libre du choix, la solution texte (ASCII, par exemple) est recommandée, car elle est très simple. Seul défaut, elle prend plus de place pour les valeurs numériques, surtout si on veut de la précision (décimaux, quoique que la notation scientifique soit parfois plus compacte... à voir au cas par cas).

Les problèmes de portabilité (fin de lignes, ASCII vs EBCDIC) sont extrêmement limités, biens définis et facile à contourner. Ca peut être un peu plus chaud si on est en mode caractères multibytes (Unicode et autres). Mais je pense que le convention est la même partout : MSB en tête.

Mais parfois, le format est imposé. En SNMP, par exemple, c'est BER. Pas le choix, il faut se cogner ce format binaire...
23/01/2007, 19h51
Jean-Marc.Bourguet

Citation:

Envoyé par mujigka

La solution binaire (TLV ou XDR: http://emmanuel-delahaye.developpez....m#enreg_struct ) est-elle de manière générale à préférer à un fichier texte (du type CSV ou autre)?

Ça dépend du contexte.

Citation:

Le problème de l'encodage (ASCII) est-il une limitation importante d'un point de vue de la portabilité?

L'important est que le format soit bien défini. Et donc il faut de toute manière fixer un encodage pour les caractères s'il y en a. Après... j'ai tendance à considérer qu'il faut préférer un format texte tant qu'on n'est pas certain qu'un format binaire apporte des avantages.
23/01/2007, 20h09
Thierry Chappuis

Citation:

Envoyé par Emmanuel Delahaye

Ca dépend des contraintes. Si on est libre du choix, la solution texte (ASCII, par exemple) est recommandée, car elle est très simple. Seul défaut, elle prend plus de place pour les valeurs numériques, surtout si on veut de la précision (décimaux, quoique que la notation scientifique soit parfois plus compacte... à voir au cas par cas).

Les problèmes de portabilité (fin de lignes, ASCII vs EBCDIC) sont extrêmement limités, biens définis et facile à contourner. Ca peut être un peu plus chaud si on est en mode caractères multibytes (Unicode et autres). Mais je pense que le convention est la même partout : MSB en tête.

Mais parfois, le format est imposé. En SNMP, par exemple, c'est BER. Pas le choix, il faut se cogner ce format binaire...

Merci, Emmanuel et Jean-Marc

Thierry
23/01/2007, 21h49
Médinoc

Citation:

Mais je pense que le convention est la même partout : MSB en tête.

Justement pas en unicode sous Windows: C'est tout en UTF-16 LE ou (UCS-2 LE avant).
D'ailleurs, la CRT 8.0, qui supporte nativement l'ouverture de fichiers en unicode, ne supporte hélas pas l'UTF-16 BE...
24/01/2007, 00h50
Emmanuel Delahaye

Citation:

Envoyé par Médinoc

Justement pas en unicode sous Windows: C'est tout en UTF-16 LE ou (UCS-2 LE avant).
D'ailleurs, la CRT 8.0, qui supporte nativement l'ouverture de fichiers en unicode, ne supporte hélas pas l'UTF-16 BE...

Quels gros nuls. Même pas foutus de respecter les conventions... Ca m'énerve...
24/01/2007, 09h02
JeitEmgie

Citation:

Envoyé par Médinoc

Justement pas en unicode sous Windows: C'est tout en UTF-16 LE ou (UCS-2 LE avant).
D'ailleurs, la CRT 8.0, qui supporte nativement l'ouverture de fichiers en unicode, ne supporte hélas pas l'UTF-16 BE...

si c'est le cas alors elle ne peut pas prétendre être compatible Unicode :

un fichier UTF-16 soit commence par le BOM (0XFEFF pour BE, 0xFFFE pour LE), soit est big endian…

selon les specs, UTF-16 sans BOM en LE, c'est pas … de l'Unicode …
24/01/2007, 10h07
Jean-Marc.Bourguet

Citation:

Envoyé par JeitEmgie

si c'est le cas alors elle ne peut pas prétendre être compatible Unicode :

un fichier UTF-16 soit commence par le BOM (0XFEFF pour BE, 0xFFFE pour LE), soit est big endian…

selon les specs, UTF-16 sans BOM en LE, c'est pas … de l'Unicode …

Reference? A ma connaissance Unicode n'impose rien du tout et laisse a des conventions externes (ils parlent de protocole) le choix d'exiger, d'interdire ou de rendre facultatif le BOM dans des donnees. Une BDD peut parfaitement stocker les champs textes en UTF-16LE sans mettre un BOM au debut de chacun des champs.

(J'ai cru comprendre que pour Windows, MS avait decide qu'un BOM etait obligatoire pour les fichiers textes encode en unicode).
24/01/2007, 10h11
Médinoc
1. Il n'y a pas de "pas foutus de respecter les conventions" ici, puisque c'est déjà une extension. Et le choix doit être dû au fait que la plupart des plate-formes Windows tournent sur du intel, donc tout texte en UTF-16 est en LE en mémoire...
2. Je n'ai jamais dit "sans BOM"... La BOM est présente et lue, elle peut même permettre de différencier entre UTF-8 et UTF-16 LE, mais l'extension de lecture ne supporte pas l'UTF-16 BE...
PS: Cela concerne uniquement la CRT de microsoft. Le framework .Net, lui, supporte tous les encodages Unicode, plus toutes les codepages Windows...
Extension d'encodage de la CRT 8.0
Encodages supportés par .Net
24/01/2007, 10h14
Médinoc

La BOM est sans doute obligatoirement mise par les programmes et API "fichier texte" de Microsoft.

Au passage, le problème du "bush hid the facts" dans Notepad vient du fait que pour les fichiers sans BOM, Notepad utilise une heuristique (la fonction IsTextUnicode()) pour savoir si le fichier ne serait pas quand même un fichier unicode dont la BOM aurait été oubliée. Heureusement, ce test est effectué quand on sélectionne le fichier dans la boîte de dialogue d'ouverture, ce qui permet de forcer manuellement le mode d'ouverture avant de cliquer sur OK...
24/01/2007, 10h58
JeitEmgie

Citation:

Envoyé par Jean-Marc.Bourguet

Reference? A ma connaissance Unicode n'impose rien du tout et laisse a des conventions externes (ils parlent de protocole) le choix d'exiger, d'interdire ou de rendre facultatif le BOM dans des donnees. Une BDD peut parfaitement stocker les champs textes en UTF-16LE sans mettre un BOM au debut de chacun des champs.

évidemment ! et heureusement…

comme vous dites, ce que dit Unicode, c'est que sans BOM, le LE/BE doit être spécifié par le "protocole", donc de manière externe au stream de bytes…
(et dans ce cas il NE peut PAS avoir de BOM…)

dans le cas de l'exemple de la BDD, cela veut simplement dire que le fait que les champs sont en UTF-16LE est spécifié dans son mode d'emploi, dans un paramètre d'exploitation, …

mais quand ni l'un ni l'autre ne sont spécifiés : càd quand vous recevez un UTF-16 sans plus d'explication et qu'il n'y a pas de BOM alors il faudrait supposer le BE…
(fallait bien en choisir un des deux, et c'est le plus "lisible par un humain" qui a été pris…)

mais rien ne vous empêche d'essayer les 2 dans vos programmes…
le but étant toujours d'obtenir une solution qui satisfasse l'utilisateur final avant tout…

Fuseau horaire GMT +2. Il est actuellement 11h43.