Souvent je vois parler du `padding', et ne sachant pas ce que c'est
j'ai parfois du mal a comprendre certain post.
Quelqu'un peut me dire ce qu'est le padding
Merci beaucoup.
sachant que la taille des types (genre int sur 16 ou 32 bits selon le compilo et la plateforme) peut aussi varier, tu te d,finiras surement u8, u16 et u32 au d,but
Tu veux dire qu'on définira u8 différement selon le type de plateforme avec
des #ifdef ??
Tu pourrais donner un exemple de deux ou trois définitions de u8 ?
Merci
typedef char u8; typedef short int u16; typedef long int u32; typedef long long int u48;
en général, les u sont pour les unsigned, sinon c'est s8, s16, ... (et alors là, vérifie bien que la gestion du signe suivant la plateforme !) long long => u64
"David Roman" <roman@cesr.fr> a écrit dans le message de
news:3F8E810F.AB03C7D@cesr.fr...
Zouplaz wrote:
Al 1 - ol1@free.xx :
sachant que la taille des types (genre int sur 16 ou 32 bits selon le
compilo et la plateforme) peut aussi varier, tu te d,finiras surement
u8, u16 et u32 au d,but
Tu veux dire qu'on définira u8 différement selon le type de plateforme
avec
des #ifdef ??
Tu pourrais donner un exemple de deux ou trois définitions de u8 ?
Merci
typedef char u8;
typedef short int u16;
typedef long int u32;
typedef long long int u48;
en général, les u sont pour les unsigned, sinon c'est s8, s16, ...
(et alors là, vérifie bien que la gestion du signe suivant la plateforme !)
long long => u64
sachant que la taille des types (genre int sur 16 ou 32 bits selon le compilo et la plateforme) peut aussi varier, tu te d,finiras surement u8, u16 et u32 au d,but
Tu veux dire qu'on définira u8 différement selon le type de plateforme avec
des #ifdef ??
Tu pourrais donner un exemple de deux ou trois définitions de u8 ?
Merci
typedef char u8; typedef short int u16; typedef long int u32; typedef long long int u48;
en général, les u sont pour les unsigned, sinon c'est s8, s16, ... (et alors là, vérifie bien que la gestion du signe suivant la plateforme !) long long => u64
Anthony Fleury
[snip exemple et explications sur le padding]
reste que lorsqu'il doit placer une valeur dans "a", je pense que le processeur doit soit avoir un accès 8 bit explicite, soit faire un calcul de masque binaire avant d'écrire l'entier.
(Veuillez corriger ou commenter si besoin)
Ca dépend de l'architecture en fait. À ma connaissance il y a deux types d'architectures : - Celles qui autorisent l'accès non aligné. Elles n'ont en général pas d'accès 8 bits, les lignes d'adresses de poids faibles étant parfois utilisées pour autre chose, mais par contre elles s'arrangent pour permettre des accès en lecture ou en écriture non aligné mais avec des vitesses d'execution plus lentes. Celle que je connais fait ca avec des opérations logiques et deux lectures... Les autres ca doit être dans le même genre.
- D'autres par contre, telle que le MIPS et quelques autres RISC, n'ont pas de lignes d'adresses 0 et 1 mais en plus interdisent totalement les accès non alignés. C'est donc dans ce cas au compilateur de s'arranger pour que tous les accès se fassent en alignés. Dans les exemples que j'ai vu ca multiplie par exemple la taille d'un tableau de char par 4 vu que chaque char "occupera" 4 bytes, avec 3 de padding.
[snip exemple et explications sur le padding]
reste que lorsqu'il doit placer une valeur dans "a", je pense que le
processeur doit soit avoir un accès 8 bit explicite, soit faire un
calcul de masque binaire avant d'écrire l'entier.
(Veuillez corriger ou commenter si besoin)
Ca dépend de l'architecture en fait. À ma connaissance il y a deux types
d'architectures :
- Celles qui autorisent l'accès non aligné. Elles n'ont en général pas
d'accès 8 bits, les lignes d'adresses de poids faibles étant parfois
utilisées pour autre chose, mais par contre elles s'arrangent pour permettre
des accès en lecture ou en écriture non aligné mais avec des vitesses
d'execution plus lentes. Celle que je connais fait ca avec des opérations
logiques et deux lectures... Les autres ca doit être dans le même genre.
- D'autres par contre, telle que le MIPS et quelques autres RISC, n'ont pas
de lignes d'adresses 0 et 1 mais en plus interdisent totalement les accès
non alignés. C'est donc dans ce cas au compilateur de s'arranger pour que
tous les accès se fassent en alignés. Dans les exemples que j'ai vu ca
multiplie par exemple la taille d'un tableau de char par 4 vu que chaque
char "occupera" 4 bytes, avec 3 de padding.
reste que lorsqu'il doit placer une valeur dans "a", je pense que le processeur doit soit avoir un accès 8 bit explicite, soit faire un calcul de masque binaire avant d'écrire l'entier.
(Veuillez corriger ou commenter si besoin)
Ca dépend de l'architecture en fait. À ma connaissance il y a deux types d'architectures : - Celles qui autorisent l'accès non aligné. Elles n'ont en général pas d'accès 8 bits, les lignes d'adresses de poids faibles étant parfois utilisées pour autre chose, mais par contre elles s'arrangent pour permettre des accès en lecture ou en écriture non aligné mais avec des vitesses d'execution plus lentes. Celle que je connais fait ca avec des opérations logiques et deux lectures... Les autres ca doit être dans le même genre.
- D'autres par contre, telle que le MIPS et quelques autres RISC, n'ont pas de lignes d'adresses 0 et 1 mais en plus interdisent totalement les accès non alignés. C'est donc dans ce cas au compilateur de s'arranger pour que tous les accès se fassent en alignés. Dans les exemples que j'ai vu ca multiplie par exemple la taille d'un tableau de char par 4 vu que chaque char "occupera" 4 bytes, avec 3 de padding.
Erwan David
"Anthony Fleury" écrivait :
- D'autres par contre, telle que le MIPS et quelques autres RISC, n'ont pas de lignes d'adresses 0 et 1 mais en plus interdisent totalement les accès non alignés. C'est donc dans ce cas au compilateur de s'arranger pour que tous les accès se fassent en alignés. Dans les exemples que j'ai vu ca multiplie par exemple la taille d'un tableau de char par 4 vu que chaque char "occupera" 4 bytes, avec 3 de padding.
Certains feront ça par un accès aligné puis décalage pour amener l'octet qui va bien au début de la valeur. Mais de toute façon ici on s'en fout un peu : si on code proprement en C c'est le compilateur qui s'occupera de ce genre de choses.
- D'autres par contre, telle que le MIPS et quelques autres RISC, n'ont pas
de lignes d'adresses 0 et 1 mais en plus interdisent totalement les accès
non alignés. C'est donc dans ce cas au compilateur de s'arranger pour que
tous les accès se fassent en alignés. Dans les exemples que j'ai vu ca
multiplie par exemple la taille d'un tableau de char par 4 vu que chaque
char "occupera" 4 bytes, avec 3 de padding.
Certains feront ça par un accès aligné puis décalage pour amener
l'octet qui va bien au début de la valeur. Mais de toute façon ici on
s'en fout un peu : si on code proprement en C c'est le compilateur qui
s'occupera de ce genre de choses.
- D'autres par contre, telle que le MIPS et quelques autres RISC, n'ont pas de lignes d'adresses 0 et 1 mais en plus interdisent totalement les accès non alignés. C'est donc dans ce cas au compilateur de s'arranger pour que tous les accès se fassent en alignés. Dans les exemples que j'ai vu ca multiplie par exemple la taille d'un tableau de char par 4 vu que chaque char "occupera" 4 bytes, avec 3 de padding.
Certains feront ça par un accès aligné puis décalage pour amener l'octet qui va bien au début de la valeur. Mais de toute façon ici on s'en fout un peu : si on code proprement en C c'est le compilateur qui s'occupera de ce genre de choses.
Emmanuel Delahaye
In 'fr.comp.lang.c', David Roman wrote:
Quelqu'un peut me dire ce qu'est le padding
C'est pas un gateau anglais?
;-)
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', David Roman <roman@cesr.fr> wrote:
Quelqu'un peut me dire ce qu'est le padding
C'est pas un gateau anglais?
;-)
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Ca ve dire qu'en memoire la taille de la srtucture est de 12 au lieu de 6 ??? Que se passe t-il si on l'ecrit dans un fichier ??? a 0 0 0 0 0 0 4 b 0 0 0 ou a 0 0 0 4 b
Faut pas faire ça. Il est absurde de vouloir enregistrer des représentations mémoire dans un fichier. Ca ne rime à rien et ce n'est absolument pas portable. Il suffit que les reglages d'alignement changent, et il sera impossible de relire le fichier.
Un fichier est un flux de bytes. Il faut donc convertir les données en un flux de bytes. Une bonne méthode simple et quasiment portable est la conversion en chaines de caractères.
Il existe d'autres formats portables standardisées comme XDR (RFC 1014, 1832 etc.)
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', David Roman <roman@cesr.fr> wrote:
Ca ve dire qu'en memoire la taille de la srtucture est de 12 au lieu de 6
???
Que se passe t-il si on l'ecrit dans un fichier ???
a 0 0 0 0 0 0 4 b 0 0 0
ou
a 0 0 0 4 b
Faut pas faire ça. Il est absurde de vouloir enregistrer des représentations
mémoire dans un fichier. Ca ne rime à rien et ce n'est absolument pas
portable. Il suffit que les reglages d'alignement changent, et il sera
impossible de relire le fichier.
Un fichier est un flux de bytes. Il faut donc convertir les données en un
flux de bytes. Une bonne méthode simple et quasiment portable est la
conversion en chaines de caractères.
Il existe d'autres formats portables standardisées comme XDR (RFC 1014, 1832
etc.)
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Ca ve dire qu'en memoire la taille de la srtucture est de 12 au lieu de 6 ??? Que se passe t-il si on l'ecrit dans un fichier ??? a 0 0 0 0 0 0 4 b 0 0 0 ou a 0 0 0 4 b
Faut pas faire ça. Il est absurde de vouloir enregistrer des représentations mémoire dans un fichier. Ca ne rime à rien et ce n'est absolument pas portable. Il suffit que les reglages d'alignement changent, et il sera impossible de relire le fichier.
Un fichier est un flux de bytes. Il faut donc convertir les données en un flux de bytes. Une bonne méthode simple et quasiment portable est la conversion en chaines de caractères.
Il existe d'autres formats portables standardisées comme XDR (RFC 1014, 1832 etc.)
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Emmanuel Delahaye
In 'fr.comp.lang.c', David Roman wrote:
Comment empecher le padding, surtout si on veux relire un fichier avec un structure de ce type ??
La conception doit s'affranchir de ce problème. Ce n'est pas en bidouillant qu'on y arrivera. Sur certaines architectures, les contraintes d'alignement sont imposées. Par exemple en 68000, un accès 16 bits à une adresse impaire provoque un trap BERR (Bus ERRor). Il n'y a donc pas de solution autre qu'une bonne conception (Texte, XDR etc.).
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', David Roman <roman@cesr.fr> wrote:
Comment empecher le padding, surtout si on veux relire un fichier avec
un structure de ce type ??
La conception doit s'affranchir de ce problème. Ce n'est pas en bidouillant
qu'on y arrivera. Sur certaines architectures, les contraintes d'alignement
sont imposées. Par exemple en 68000, un accès 16 bits à une adresse impaire
provoque un trap BERR (Bus ERRor). Il n'y a donc pas de solution autre qu'une
bonne conception (Texte, XDR etc.).
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Comment empecher le padding, surtout si on veux relire un fichier avec un structure de ce type ??
La conception doit s'affranchir de ce problème. Ce n'est pas en bidouillant qu'on y arrivera. Sur certaines architectures, les contraintes d'alignement sont imposées. Par exemple en 68000, un accès 16 bits à une adresse impaire provoque un trap BERR (Bus ERRor). Il n'y a donc pas de solution autre qu'une bonne conception (Texte, XDR etc.).
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Eddahbi Karim
On 16 Oct 2003 17:44:56 GMT Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', David Roman wrote:
Quelqu'un peut me dire ce qu'est le padding
C'est pas un gateau anglais?
;-)
C'est là tout le danger...
-- -- ThE_TemPLaR
On 16 Oct 2003 17:44:56 GMT
Emmanuel Delahaye <emdelYOURBRA@noos.fr> wrote:
In 'fr.comp.lang.c', David Roman <roman@cesr.fr> wrote:
On 16 Oct 2003 17:44:56 GMT Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', David Roman wrote:
Quelqu'un peut me dire ce qu'est le padding
C'est pas un gateau anglais?
;-)
C'est là tout le danger...
-- -- ThE_TemPLaR
Frédéri MIAILLE
Question : Si je compile ma structure sous le système imaginaire Vindauze et que je l'écris en fichier avec un sizeof(struct). Ensuite, j'envoie ce fichier par le réseau. Je lis ce fichier avec un sizeof(struct) mais compilé sous un autre système imaginaire de type LiNouxe. Si le padding n'est pas le même, mon sizeof ne donnera pas la même taille d'un système à l'autre et ma structure serait mal interprétée ? Solution ? Compiler sous deux os qui ont le même padding et livrer les exécutables qui pourraient alors fonctionner sous des os compatibles qui ont un padding qui n'est alors pas pris en compte ? Encore des cauchemards en perspective tiens !
Question :
Si je compile ma structure sous le système imaginaire Vindauze et que je
l'écris en fichier avec un sizeof(struct).
Ensuite, j'envoie ce fichier par le réseau.
Je lis ce fichier avec un sizeof(struct) mais compilé sous un autre système
imaginaire de type LiNouxe.
Si le padding n'est pas le même, mon sizeof ne donnera pas la même taille
d'un système à l'autre et ma structure serait mal interprétée ?
Solution ?
Compiler sous deux os qui ont le même padding et livrer les exécutables qui
pourraient alors fonctionner sous des os compatibles qui ont un padding qui
n'est alors pas pris en compte ?
Encore des cauchemards en perspective tiens !
Question : Si je compile ma structure sous le système imaginaire Vindauze et que je l'écris en fichier avec un sizeof(struct). Ensuite, j'envoie ce fichier par le réseau. Je lis ce fichier avec un sizeof(struct) mais compilé sous un autre système imaginaire de type LiNouxe. Si le padding n'est pas le même, mon sizeof ne donnera pas la même taille d'un système à l'autre et ma structure serait mal interprétée ? Solution ? Compiler sous deux os qui ont le même padding et livrer les exécutables qui pourraient alors fonctionner sous des os compatibles qui ont un padding qui n'est alors pas pris en compte ? Encore des cauchemards en perspective tiens !
Question : Si je compile ma structure sous le système imaginaire Vindauze et que je l'écris en fichier avec un sizeof(struct). Ensuite, j'envoie ce fichier par le réseau. Je lis ce fichier avec un sizeof(struct) mais compilé sous un autre système imaginaire de type LiNouxe. Si le padding n'est pas le même, mon sizeof ne donnera pas la même taille d'un système à l'autre et ma structure serait mal interprétée ? Solution ? Compiler sous deux os qui ont le même padding et livrer les exécutables qui pourraient alors fonctionner sous des os compatibles qui ont un padding qui n'est alors pas pris en compte ? Encore des cauchemards en perspective tiens !
Non la solution est de définir colmplètement un format de transport qui n'est pas le simple dump de la structure en mémoire.
Question :
Si je compile ma structure sous le système imaginaire Vindauze et que je
l'écris en fichier avec un sizeof(struct).
Ensuite, j'envoie ce fichier par le réseau.
Je lis ce fichier avec un sizeof(struct) mais compilé sous un autre système
imaginaire de type LiNouxe.
Si le padding n'est pas le même, mon sizeof ne donnera pas la même taille
d'un système à l'autre et ma structure serait mal interprétée ?
Solution ?
Compiler sous deux os qui ont le même padding et livrer les exécutables qui
pourraient alors fonctionner sous des os compatibles qui ont un padding qui
n'est alors pas pris en compte ?
Encore des cauchemards en perspective tiens !
Non la solution est de définir colmplètement un format de transport
qui n'est pas le simple dump de la structure en mémoire.
Question : Si je compile ma structure sous le système imaginaire Vindauze et que je l'écris en fichier avec un sizeof(struct). Ensuite, j'envoie ce fichier par le réseau. Je lis ce fichier avec un sizeof(struct) mais compilé sous un autre système imaginaire de type LiNouxe. Si le padding n'est pas le même, mon sizeof ne donnera pas la même taille d'un système à l'autre et ma structure serait mal interprétée ? Solution ? Compiler sous deux os qui ont le même padding et livrer les exécutables qui pourraient alors fonctionner sous des os compatibles qui ont un padding qui n'est alors pas pris en compte ? Encore des cauchemards en perspective tiens !
Non la solution est de définir colmplètement un format de transport qui n'est pas le simple dump de la structure en mémoire.
