"packed record" en C ?

Bonjour à tous.

Existe-t-il un équivalent C à "packed record" (Pascal) ?

"packed record" ... ce n'est pas du C bien entendu, c'est du Pascal. Il s'agit d'une directive donnée au compilateur Pascal et qui concerne les "structures". Avec "packed record" on est certain que la structure se trouve en mémoire comme elle a été déclarée ... sans allignement, sans être scindée.

En C ...
En ce qui concerne l'allignement, j'ai "# pragma (push,1)". Ceci va forcer le compilo C a considérer le byte et rien d'autres. Donc pas d'allignement.

mais ... ce "non-allignement", en théorie, n'empeche pas le compilo C de scinder la structure en parties non contigues physiquement ! Existe-t-il, en C, une directive qui permet d'être certain que ma structure se trouve physiquement en mémoire en "un seul bloc continu" ?

Merci à tous et une toute bonne journée. ;)

Il y a les directives "#pragma pack" et "#pragma align" pour faire l'équivalent. Je ne sais pas si le compilateur est ''obligé" de se soumettre à la directive ou si de toute façon, il fait ce qu'il veut.

Juste une remarque en passant, dès que l'on a besoin de jouer avec ses directives, cela devient un peu risqué.

Dans ces cas, je préfère utiliser un tableau de unsigned char et "jouer" avec les offsets dans ce tableau (même si certaines valeurs sont sur 2 ou 4 octets)

Bien entendu que le compilateur est "obligé" de suivre les directives que tu lui donnes ;) ... Les directives "pragma" sont mêmes prioritaires sur tous autres directives de compilation (/Zp par exemple). Si tu lui donnes la directive "#pragma pack (push,1) / #pragma pack (pop)", entre les deux tu lui interdis tout allignement au delà du byte ... donc pas d'allignement ! Un compilo, ça ne "pense" pas, et ça ne fait pas ce qu'il veut "malgré tout" ... pas de tracas. hi

"#pragma align" ne semble pas exister pour le compilo C de Microsoft ... en tout cas pas dans celui de Visual Studio 2005 ou 2008. Mais "#pragma pack (push , n) suffit pour toutes questions d'allignement.

Bon ...
Tout ceci ne m'apporte pas de réponse à ma question.
Avec "#pragma pack (push,1), je sais que tous les champs de ma structure se retrouvent physiquement tel quel en mémoire. Mais cela, dans l'absolu, n'empêche pas le compilo de "couper" physiquement ma structure "entre 2 champs".

En Pascal, "Packed Reccord" interdit cela ... mais en C ???

ps
---
Le fait ne "jouer" avec un tableau de "byte" n'enlève pas le risque que ce tableau soit découpé physiquement par le compilo. Ce découpage est transparent dans la plupart des cas ... si tu y fais référence "normalement", tu ne t'en apercevras jamais. Sauf si tu essayes de récupérer en une seule fois, 2 bytes consécutifs, dans un word.

Bonjour,

A ma connaissance, #pragma pack assure qu'il n'y aura pas de padding dans la structure (a contrario de __declspec align qui aligne la base de la structure et pad les champs pour qu'ils soient alignés).

Dans Winnt.h on trouve plusieurs structures packées de la sorte grâce à des en-têtes.

On trouve ça, par exemple, dans le fichier d'en-tête pshpack1.h

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

/*++   Copyright (c) Microsoft Corporation. All rights reserved.   Module Name:     pshpack1.h   Abstract:     This file turns 1 byte packing of structures on. (That is, it disables   automatic alignment of structure fields.) An include file is needed   because various compilers do this in different ways. For Microsoft   compatible compilers, this files uses the push option to the pack pragma   so that the poppack.h include file can restore the previous packing   reliably.     The file poppack.h is the complement to this file.   --*/

---

A partir du moment où la structure est packée sur un octet, il ne peut pas y avoir de padding entre deux champs.

Citation:

---

Envoyé par - Robby -

Existe-t-il un équivalent C à "packed record" (Pascal) ?

"packed record" ... ce n'est pas du C bien entendu, c'est du Pascal. Il s'agit d'une directive donnée au compilateur Pascal et qui concerne les "structures". Avec "packed record" on est certain que la structure se trouve en mémoire comme elle a été déclarée ...

---

Pas de manière portable, parce que le C est universel et que sur certaines plateformes, c'est tout simplement impossible.

Par contre, ça peut exister sur certains compilateurs. A manier avec précaution en sachant que ce code n'est pas portable.

Citation:

---

sans allignement, sans être scindée.

En C ...
En ce qui concerne l'allignement, j'ai "# pragma (push,1)". Ceci va forcer le compilo C a considérer le byte et rien d'autres. Donc pas d'allignement.

mais ... ce "non-allignement", en théorie, n'empeche pas le compilo C de scinder la structure en parties non contigues physiquement ! Existe-t-il, en C, une directive qui permet d'être certain que ma structure se trouve physiquement en mémoire en "un seul bloc continu" ?

---

Attention, l'alignement n'a rien à voir avec la contigüité qui, elle est toujours garantie tant que la structure est linéaire (pas de pointeurs).

L'alignement concerne des contraintes physiques liées à l'architecture. Par exemple sur Freescale PowerPC, on ne sait pas accéder à un objet de 16-bit à une adresse impaire. Ca signifie que

Code:

---

1 2 3 4 5 6 7

/* taille valides sur Power PC ou x86 */ struct st { char x; /* 8-bit */ short y; /* 16-bit */ };

---

sera obligatoirement encodé :

Code:

---

1 2 3 4 5

[0] x [1] padding [2] MSB y (adresse paire) [3] LSB y

---

Par contre, sur x86, elle sera codée par défaut

Code:

---

1 2 3 4 5

[0] x [1] padding [2] LSB y (adresse paire) [3] MSB y

---

car l'accès 16-bit sur adresse paire est plus rapide (en une fois 16-bit), mais il est possible (au prix d'une réduction de performances : accès en 2 fois 8-bit) de compresser la structure comme ceci :

Code:

---

1 2 3 4

[0] x [1] LSB y (adresse impaire) [2] MSB y

---

Neitsa ;) ... ça fait longtemps pardi !
Oups, on a pris du galon ici ... respect ici !
Bon ...
Merci pour ta réponse.
Oui, je connais et j'utilise le fichier d'en-tête pshpack1.h.

Il est certain que la directive "#pragma pack (push,1)" force le compilateur à aligner les champs de la structure sur le byte. Mais ... et je vais essayer de me faire comprendre, c'est pas toujours facile uniquement par écrit ... le compilateur considère-t-il que le fait de découper physiquement la structure en 2 moitiés constitue, pour la 2eme moitié, une forme d'alignement ? L'alignement concerne des "ajustements" de 2, 4 ou 8 bytes ... mais si le compilateur, pour des raisons qui lui sont propres (gestion mémoire, peu importe) décide de placer la 2eme moitié de ma structure à l'autre bout du segment de données ... considère-t-il qu'il s'agit aussi d'un alignement, et donc que cela lui est interdit ?

Oui, je cherche le "fin du fin" ici ;) ... mais parfois, c'est intéressant de savoir exactement ce qu'il se passe. Surtout ici, dans mon cas.

Voila, que penses-tu de ma remarque Neitsa ?
Confirmes-tu que "#pragma pack (push,1)" suffit à interdire, dans tous les cas, toutes formes de morcellement de la structure ?

Merci à toi ;)

Edit :
désolé Mr Delahaye, nous avons "posté" en même temps.
==> " l'alignement n'a rien à voir avec la contigüité "
Je suis d'accord avec ça !

Citation:

---

Envoyé par - Robby -

Edit :
désolé Mr Delahaye, nous avons "posté" en même temps.
==> " l'alignement n'a rien à voir avec la contigüité "
Je suis d'accord avec ça !

---

Ah bon ? Parce qu'à te lire, tu as toujours l'air de croire que le C autorise le compilateur à découper la structure en parties non contigües ou dans des segments différents. Ce n'est pas le cas. Il autorise l'alignement (et donc le padding ou bourrage), c'est tout.

Je le répète, la contigüité est garantie (elle inclue le bourrage éventuel). Bien sûr, la taille maximale d'un objet (bourrage inclus) est définie par le compilateur. Elle ne peut être inférieure à 32767 en C90 et 65535 en C99.

Citation:

---

Parce qu'à te lire, tu as toujours l'air de croire que le C autorise le compilateur à découper la structure en parties non contigües ou dans des segments différents. Ce n'est pas le cas. Il autorise l'alignement (et donc le padding ou bourrage), c'est tout.

---

Oui, je pensais que C pouvait gérer la disposition physique en mémoire comme il le désirait. Donc, ce n'est pas le cas ? Ah bon ... savais pas.

Donc, "#pragma pack (push,1)" suffit bien à interdire toutes formes d'alignements ... de padding et de "non-contiguité" !

Merci beaucoup !

Citation:

---

Envoyé par - Robby -

Oui, je pensais que C pouvait gérer la disposition physique en mémoire comme il le désirait.

---

Non. En C, on a pas accès à la mémoire physique, du moins de manière standard. On ne connait que la mémoire 'logique' (les 'adresses' sont en réalité des identificateurs numériques qui n'ont que très rarement une réalité physique, MMU oblige...)

Citation:

---

Donc, "#pragma pack (push,1)" suffit bien à interdire toutes formes d'alignements ... de padding et de "non-contiguité" !

---

• C'est écrit dans la doc de ton compilateur
• Ce n'est pas portable.

Citation:

---

on a pas accès à la mémoire physique, du moins de manière standard. On ne connait que la mémoire 'logique'.

---

Oui, oui, je sais ça. ;)

Citation:

---

C'est écrit dans la doc de ton compilateur

---

Ah bon ... ? :? ... La doc de mon Compilateur ? Y'a une doc avec mon compilateur ? :oops: ... J'utilise VS C++ 2008, et puisqu'on parle d'emplacement physique, elle est ou cette doc ? Dans la librairie msdn qui va avec ?

Citation:

---

Envoyé par - Robby -

Oui, oui, je sais ça. ;)

---

Alors cesse de sortir des énormités comme ça :

Citation:

---

Oui, je pensais que C pouvait gérer la disposition physique en mémoire comme il le désirait.

---

admets simplement que tu t'es trompé c'est tout.

Citation:

---

La doc de mon Compilateur ? Y'a une doc avec mon compilateur ?

---

Oui.

Citation:

---

J'utilise VS C++ 2008, et puisqu'on parle d'emplacement physique, elle est ou cette doc ? Dans la librairie msdn qui va avec ?

---

Pas dans la partie bibliothèque (library), évidemment, mais dans la section VC++, oui, certainement. Il faut que je cherche à ta place ou tu vas y arriver tout seul ?

Oui, je me suis mal exprimé, en effet.
Comment C pourrait-il gérer la mémoire physique !!!
C'est en effet une énormité.
J'admets ;)

Je pense pouvoir y arriver tout seul ! ;)

Entre nous, je suis déjà allé voir dans la doc msdn, un peu partout. On y parle en effet de "#pragma pack". On en parle en termes d'alignemets. Mais je n'ai trouvé nul part d'info concernant la "non-(non-contigüité)".

EDIT
----
Ok, j'ai compris !
Je viens de me rendre compte que ... bien que "sachant" ;) ... je confonds gestion "logique" et "physique" de la mémoire. Quand on a compris "ça" ... il devient évident que "#pragma pack 1" suffit à rendre la structure "logiquement" contigüe.

Citation:

---

Envoyé par - Robby -

Entre nous, je suis déjà allé voir dans la doc msdn, <...> Mais je n'ai trouvé nul part d'info concernant la "non-(non-contigüité)".

---

Double négation ? Je suis perdu (pas assez de neurones, désolé). Si tu parles de la contigüité, c'est dans la norme qui définit le langage C.

http://emmanuel-delahaye.developpez.com/notes.htm#norme

Citation:

---

je suis perdu (pas assez de neurones, désolé)

---

J'en doute ;)

Citation:

---

concernant la "non-(non-contigüité)"

---

Concernant le fait que "#pragma pack 1" empeche la non-contigüité en mémoire ... logique.

J'ai édité mon article précédent ... le "franc" est tombé.

Citation:

---

Envoyé par - Robby -

Concernant le fait que "#pragma pack 1" empeche la non-contigüité en mémoire ... logique.

---

Je ne comprends pas cette histoire de non contigüité. Ca n'existe pas. Point. Le C garanti la contigüité. Elle inclue les éventuels bytes de bourrage liés à l'implémentation. Point.

Ca ne dépend ni de la nature de la mémoire (physique, logique, qui est une question système qui n'a rien à voir avec le C), ni des directives ou configurations d'alignement ou de compression qui sont des caractéristiques de l'implémentation.

C'est clair cette fois ? Je ne veux plus entendre parler de "non-contigüité", ça n'existe pas.

OK !

Il s'agit alors d'une caractéristique du language C.

Il semble que Pascal n'offre pas cette "indiscutabilité".
L'existence en Pascal de "Packed Record", ainsi que sa définition, en est la preuve. Pascal dans ce cas, ne parle pas uniquement d'alignement mais également de structure rendue de cette façon "mono-bloc".

"Point" donc ! si cela est votre souhait.

Merci pour cet échange.

Citation:

---

Envoyé par - Robby -

Il s'agit alors d'une caractéristique du language C.

---

Tu comprends vite, mais il faut t'expliquer longtemps... language ?

Citation:

---

Il semble que Pascal n'offre pas cette "indiscutabilité".
L'existence en Pascal de "Packed Record", ainsi que sa définition, en est la preuve. Pascal dans ce cas, ne parle pas uniquement d'alignement mais également de structure rendue de cette façon "mono-bloc".

---

Hors-sujet.

http://www.developpez.net/forums/forumdisplay.php?f=21

Citation:

---

Tu comprends vite, mais il faut t'xpliquer longtemps...

---

Votre condescendance n'apporte rien au débat.

Non, l'équivalent Pascal n'est pas "hors-sujet".
Cela était même la base même de ma question.
L'équivalence de l'un et de l'autre.

Je vous remercie bien sincèrement pour votre aide,
et vous présente mon "point", mais cette fois le mien.

respect.

Je ne connais pas la portabilité de "__attribute__((packed))", mais j'utilise ceci (avec gcc linux/windows):

Code:

---

1 2 3 4 5 6 7

// Structure d'un message CAN struct stCanMsg { unsigned short id :11 ; unsigned char dlc : 4 ; unsigned char data[8] ; } __attribute__((packed)) ;

---

__attribute__((packed)) c'est du GCC.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

#ifdef < un define caractéristique de GCC. __GNUC__ peut-être ? > #define ATTRIBUTE_PACKED __attribute__((packed)) #else #define ATTRIBUTE_PACKED #endif   ...   // Structure d'un message CAN #ifdef _MSC_VER #include <pshpack1.h> #endif struct stCanMsg { unsigned short id :11 ; unsigned char dlc : 4 ; unsigned char data[8] ; } ATTRIBUTE_PACKED; #ifdef _MSC_VER #include <poppack.h> #endif

---

Note: Là, on remarque qu'il est question de champs de bits: Si l'ordre ou la position des bits a la moindre importance, c'est 100% non-portable.

Pour rester portables, les champs de bits ne doivent servir qu'à économiser un peu de place. Ce qui, sur beaucoup de systèmes, est négligeable.