Est-il possible avoir un code en C capable de detecter le type de
processeur, en de lui forcer l'ecriture ou la lecture d'un fichier
binnaire en little ou big endian indifferement ???
Question aux spécialistes du C: est-il possible de concevoir une machine dont l'atome mémoire (donc la base de l'endianité) serait de 16 bits et la taille du char de 8 bits ?
Si tu parles d'une machine virtuelle pour exécuter du C, non. Si l'atome (byte) fait 16 bits, le char fait 16-bits (les 8 bits de poids forts sont en quelque sorte non utilisés). C'est le cas de certains DSP Texas.
#define CHAR_BIT 16 /* NUMBER OF BITS IN TYPE CHAR */ Bien bien. Thanks.
-- Pierre
Emmanuel Delahaye <emdel@YOURBRAnoos.fr> a écrit:
Pierre Maurette wrote on 22/10/04 :
Question aux spécialistes du C: est-il possible de concevoir une
machine dont l'atome mémoire (donc la base de l'endianité) serait de
16 bits et la taille du char de 8 bits ?
Si tu parles d'une machine virtuelle pour exécuter du C, non. Si
l'atome (byte) fait 16 bits, le char fait 16-bits (les 8 bits de poids
forts sont en quelque sorte non utilisés). C'est le cas de certains DSP
Texas.
Question aux spécialistes du C: est-il possible de concevoir une machine dont l'atome mémoire (donc la base de l'endianité) serait de 16 bits et la taille du char de 8 bits ?
Si tu parles d'une machine virtuelle pour exécuter du C, non. Si l'atome (byte) fait 16 bits, le char fait 16-bits (les 8 bits de poids forts sont en quelque sorte non utilisés). C'est le cas de certains DSP Texas.
#define CHAR_BIT 16 /* NUMBER OF BITS IN TYPE CHAR */ Bien bien. Thanks.
-- Pierre
Jean-Marc Bourguet
Emmanuel Delahaye writes:
David ROMAN wrote on 21/10/04 :
Est-il possible avoir un code en C capable de detecter le type de processeur, en de lui forcer l'ecriture ou la lecture d'un fichier binaire en little ou big endian indifferement ???
Peut être, mais ça n'a aucun intérêt. Ce problème est reglé par le choix de la cible qui se fait par compilation conditionelle.
Non. Ce probleme devrait etre regle en ecrivant du code independant de la boutitude. C'est quand meme pas complique.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Emmanuel Delahaye <emdel@YOURBRAnoos.fr> writes:
David ROMAN wrote on 21/10/04 :
Est-il possible avoir un code en C capable de detecter le type de
processeur, en de lui forcer l'ecriture ou la lecture d'un fichier
binaire en little ou big endian indifferement ???
Peut être, mais ça n'a aucun intérêt. Ce problème est reglé par le choix de
la cible qui se fait par compilation conditionelle.
Non. Ce probleme devrait etre regle en ecrivant du code independant
de la boutitude. C'est quand meme pas complique.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Est-il possible avoir un code en C capable de detecter le type de processeur, en de lui forcer l'ecriture ou la lecture d'un fichier binaire en little ou big endian indifferement ???
Peut être, mais ça n'a aucun intérêt. Ce problème est reglé par le choix de la cible qui se fait par compilation conditionelle.
Non. Ce probleme devrait etre regle en ecrivant du code independant de la boutitude. C'est quand meme pas complique.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
Emmanuel Delahaye writes:
Jean-Marc Bourguet wrote on 21/10/04 :
Toute valeur peut etre relue comme un tableau d'unsigned char.
Oui, à condition de soir ce qu'il y a dans les char.
Donc
void hexdump(void* p, size_t n, FILE* fp) { int i; unsigned char* cp = p; for (i = 0; i < n; ++i, ++cp) { fprintf(fp, "%2x", *cp); } }
est valide.
Oui, mais pas portable. L'ordre des char peut précisément changer selon l'endianness.
Ce code est conforme et permet de detecter la boutitude.
Ce qu'il faut faire, c'est utiliser un encodage qui dépend de la cible, et qui fournit un format commun (par exemple de type réseau, le 'n' de hton : MSB en tête).
C'est ce que j'ecrivais dans la suite.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Emmanuel Delahaye <emdel@YOURBRAnoos.fr> writes:
Jean-Marc Bourguet wrote on 21/10/04 :
Toute valeur peut etre relue comme un tableau d'unsigned char.
Oui, à condition de soir ce qu'il y a dans les char.
Donc
void hexdump(void* p, size_t n, FILE* fp) {
int i;
unsigned char* cp = p;
for (i = 0; i < n; ++i, ++cp) {
fprintf(fp, "%2x", *cp);
}
}
est valide.
Oui, mais pas portable. L'ordre des char peut précisément changer selon
l'endianness.
Ce code est conforme et permet de detecter la boutitude.
Ce qu'il faut faire, c'est utiliser un encodage qui dépend de la
cible, et qui fournit un format commun (par exemple de type réseau,
le 'n' de hton : MSB en tête).
C'est ce que j'ecrivais dans la suite.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Toute valeur peut etre relue comme un tableau d'unsigned char.
Oui, à condition de soir ce qu'il y a dans les char.
Donc
void hexdump(void* p, size_t n, FILE* fp) { int i; unsigned char* cp = p; for (i = 0; i < n; ++i, ++cp) { fprintf(fp, "%2x", *cp); } }
est valide.
Oui, mais pas portable. L'ordre des char peut précisément changer selon l'endianness.
Ce code est conforme et permet de detecter la boutitude.
Ce qu'il faut faire, c'est utiliser un encodage qui dépend de la cible, et qui fournit un format commun (par exemple de type réseau, le 'n' de hton : MSB en tête).
C'est ce que j'ecrivais dans la suite.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
David ROMAN writes:
David ROMAN wrote:
Est-il possible avoir un code en C capable de detecter le type de processeur, en de lui forcer l'ecriture ou la lecture d'un fichier binnaire en little ou big endian indifferement ???
Merci David
Je dois mal m'exprimer ... excusez moi ....
Bon je vais essayer de me clarifier
l'ordre des bits dans un octet ne changent pas selon les differents processeurs (est ce qu'on est ok la dessus ?)
Les processeurs transferant generalement plusieurs bits en //, il n'y a pas d'ordre. Lors des transferts en serie, il en a.
Il y a quelques processeurs (en fait seul le 8051 me vient a l'esprit pour le moment) qui permette d'acceder aux bits individuellement. Dans ces cas l'ordre peut avoir de l'importance.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
David ROMAN <roman@cesr.fr> writes:
David ROMAN wrote:
Est-il possible avoir un code en C capable de detecter le type de
processeur, en de lui forcer l'ecriture ou la lecture d'un fichier
binnaire en little ou big endian indifferement ???
Merci
David
Je dois mal m'exprimer ... excusez moi ....
Bon je vais essayer de me clarifier
l'ordre des bits dans un octet ne changent pas selon les differents
processeurs (est ce qu'on est ok la dessus ?)
Les processeurs transferant generalement plusieurs bits en //, il n'y
a pas d'ordre. Lors des transferts en serie, il en a.
Il y a quelques processeurs (en fait seul le 8051 me vient a l'esprit
pour le moment) qui permette d'acceder aux bits individuellement.
Dans ces cas l'ordre peut avoir de l'importance.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Est-il possible avoir un code en C capable de detecter le type de processeur, en de lui forcer l'ecriture ou la lecture d'un fichier binnaire en little ou big endian indifferement ???
Merci David
Je dois mal m'exprimer ... excusez moi ....
Bon je vais essayer de me clarifier
l'ordre des bits dans un octet ne changent pas selon les differents processeurs (est ce qu'on est ok la dessus ?)
Les processeurs transferant generalement plusieurs bits en //, il n'y a pas d'ordre. Lors des transferts en serie, il en a.
Il y a quelques processeurs (en fait seul le 8051 me vient a l'esprit pour le moment) qui permette d'acceder aux bits individuellement. Dans ces cas l'ordre peut avoir de l'importance.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
cedric
Jean-Marc Bourguet wrote:
Il y a quelques processeurs (en fait seul le 8051 me vient a l'esprit pour le moment) qui permette d'acceder aux bits individuellement. Dans ces cas l'ordre peut avoir de l'importance.
Le 386 et successeurs ont aussi quelques instructions pour accéder à la mémoire en bits (bc par exemple, qui si ma mémoire est bonne copie dans le flag de retenu le xième bit en partant de l'adresse donnée, x pouvant etre > à 32). Pour ces instructions, l'ordre des bits est celui "conventionnel" : le bit "0" est le bit de poids faible du premier octet. Là encore le little endianess s'avère pratique.
Jean-Marc Bourguet wrote:
Il y a quelques processeurs (en fait seul le 8051 me vient a l'esprit
pour le moment) qui permette d'acceder aux bits individuellement.
Dans ces cas l'ordre peut avoir de l'importance.
Le 386 et successeurs ont aussi quelques instructions pour accéder à la
mémoire en bits (bc par exemple, qui si ma mémoire est bonne copie dans
le flag de retenu le xième bit en partant de l'adresse donnée, x pouvant
etre > à 32).
Pour ces instructions, l'ordre des bits est celui "conventionnel" : le
bit "0" est le bit de poids faible du premier octet. Là encore le little
endianess s'avère pratique.
Il y a quelques processeurs (en fait seul le 8051 me vient a l'esprit pour le moment) qui permette d'acceder aux bits individuellement. Dans ces cas l'ordre peut avoir de l'importance.
Le 386 et successeurs ont aussi quelques instructions pour accéder à la mémoire en bits (bc par exemple, qui si ma mémoire est bonne copie dans le flag de retenu le xième bit en partant de l'adresse donnée, x pouvant etre > à 32). Pour ces instructions, l'ordre des bits est celui "conventionnel" : le bit "0" est le bit de poids faible du premier octet. Là encore le little endianess s'avère pratique.
Jean-Marc Bourguet
Pierre Maurette writes:
Question aux spécialistes du C: est-il possible de concevoir une machine dont l'atome mémoire (donc la base de l'endianité) serait de 16 bits et la taille du char de 8 bits ?
Oui. On utilise alors des pointeurs vers char qui contiennent plus d'info. C'est a cause de ce genre de machines qu'on peut avoir sizeof (int*) < sizeof(char*). Les C pour PDP-10 que j'ai vu (j'ai pas utilise le C sur ces machines mais des compilateurs C pour elles existent) ont CHAR_BIT==9 et sizeof(int)==4; mais ces machines etaient utilise avec de l'ASCII, 7 bits, 5 char par mot + 1 bit de padding ou du 6 bits , 6 char par mots et il me semble me souvenir qu'il etait possible de mettre les compilo C dans un mode plus compatible avec le systeme meme si moins conforme a l'ISO.
Alternativement on peut naturellement les faire fonctionner avec des chars equivalent au mot.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Pierre Maurette <maurettepierre@wanadoo.fr> writes:
Question aux spécialistes du C: est-il possible de concevoir une
machine dont l'atome mémoire (donc la base de l'endianité) serait de
16 bits et la taille du char de 8 bits ?
Oui. On utilise alors des pointeurs vers char qui contiennent plus
d'info. C'est a cause de ce genre de machines qu'on peut avoir sizeof
(int*) < sizeof(char*). Les C pour PDP-10 que j'ai vu (j'ai pas
utilise le C sur ces machines mais des compilateurs C pour elles
existent) ont CHAR_BIT==9 et sizeof(int)==4; mais ces machines etaient
utilise avec de l'ASCII, 7 bits, 5 char par mot + 1 bit de padding ou
du 6 bits , 6 char par mots et il me semble me souvenir qu'il etait
possible de mettre les compilo C dans un mode plus compatible avec le
systeme meme si moins conforme a l'ISO.
Alternativement on peut naturellement les faire fonctionner avec des
chars equivalent au mot.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Question aux spécialistes du C: est-il possible de concevoir une machine dont l'atome mémoire (donc la base de l'endianité) serait de 16 bits et la taille du char de 8 bits ?
Oui. On utilise alors des pointeurs vers char qui contiennent plus d'info. C'est a cause de ce genre de machines qu'on peut avoir sizeof (int*) < sizeof(char*). Les C pour PDP-10 que j'ai vu (j'ai pas utilise le C sur ces machines mais des compilateurs C pour elles existent) ont CHAR_BIT==9 et sizeof(int)==4; mais ces machines etaient utilise avec de l'ASCII, 7 bits, 5 char par mot + 1 bit de padding ou du 6 bits , 6 char par mots et il me semble me souvenir qu'il etait possible de mettre les compilo C dans un mode plus compatible avec le systeme meme si moins conforme a l'ISO.
Alternativement on peut naturellement les faire fonctionner avec des chars equivalent au mot.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Emmanuel Delahaye
Jean-Marc Bourguet wrote on 22/10/04 :
Non. Ce probleme devrait etre regle en ecrivant du code independant de la boutitude. C'est quand meme pas complique.
Tu veux dire en faisant des transferts 100% texte? Ca va pas être facile pour les fichier mp3, divx etc.
Non. Il est nécessaire d'avoir des fonctions portables ntoh/hton qui font l'abstraction en fonction de la cible, ou mieux, un protocoile de type XDR de façon à ce que les interface externes soient compatibles.
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
Jean-Marc Bourguet wrote on 22/10/04 :
Non. Ce probleme devrait etre regle en ecrivant du code independant
de la boutitude. C'est quand meme pas complique.
Tu veux dire en faisant des transferts 100% texte? Ca va pas être
facile pour les fichier mp3, divx etc.
Non. Il est nécessaire d'avoir des fonctions portables ntoh/hton qui
font l'abstraction en fonction de la cible, ou mieux, un protocoile de
type XDR de façon à ce que les interface externes soient compatibles.
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
Non. Ce probleme devrait etre regle en ecrivant du code independant de la boutitude. C'est quand meme pas complique.
Tu veux dire en faisant des transferts 100% texte? Ca va pas être facile pour les fichier mp3, divx etc.
Non. Il est nécessaire d'avoir des fonctions portables ntoh/hton qui font l'abstraction en fonction de la cible, ou mieux, un protocoile de type XDR de façon à ce que les interface externes soient compatibles.
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
Jean-Marc Bourguet
Emmanuel Delahaye writes:
Jean-Marc Bourguet wrote on 22/10/04 :
Non. Ce probleme devrait etre regle en ecrivant du code independant de la boutitude. C'est quand meme pas complique.
Tu veux dire en faisant des transferts 100% texte? Ca va pas être facile pour les fichier mp3, divx etc.
Non. J'ai donne par exemple sur ce forum des versions independantes de la boutitude du processeur pour hton et consort.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Emmanuel Delahaye <emdel@YOURBRAnoos.fr> writes:
Jean-Marc Bourguet wrote on 22/10/04 :
Non. Ce probleme devrait etre regle en ecrivant du code independant
de la boutitude. C'est quand meme pas complique.
Tu veux dire en faisant des transferts 100% texte? Ca va pas être facile
pour les fichier mp3, divx etc.
Non. J'ai donne par exemple sur ce forum des versions independantes
de la boutitude du processeur pour hton et consort.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Non. Ce probleme devrait etre regle en ecrivant du code independant de la boutitude. C'est quand meme pas complique.
Tu veux dire en faisant des transferts 100% texte? Ca va pas être facile pour les fichier mp3, divx etc.
Non. J'ai donne par exemple sur ce forum des versions independantes de la boutitude du processeur pour hton et consort.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
cedric writes:
Jean-Marc Bourguet wrote:
Il y a quelques processeurs (en fait seul le 8051 me vient a l'esprit pour le moment) qui permette d'acceder aux bits individuellement. Dans ces cas l'ordre peut avoir de l'importance.
Le 386 et successeurs ont aussi quelques instructions pour accéder à la mémoire en bits (bc par exemple, qui si ma mémoire est bonne copie dans le flag de retenu le xième bit en partant de l'adresse donnée, x pouvant etre
à 32). Pour ces instructions, l'ordre des bits est celui "conventionnel" : le bit
"0" est le bit de poids faible du premier octet. Là encore le little endianess s'avère pratique.
Ce sont des instructions de manipulation de bits. Le 8051 peut acceder a des bits individuels en memoire (pour une partie de celle-ci) sans charger le contenu dans un registre.
Dans le genre, il y a le 68000 (processeur grand boutien) qui si j'ai bonne memoire a des instructions de manipulation de bits petit boutiennnes et d'autres grand boutiennes (et je ne veux pas dire des versions d'une meme instruction...)
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
cedric <rixed@happyleptic.NOSPAM.org> writes:
Jean-Marc Bourguet wrote:
Il y a quelques processeurs (en fait seul le 8051 me vient a l'esprit
pour le moment) qui permette d'acceder aux bits individuellement.
Dans ces cas l'ordre peut avoir de l'importance.
Le 386 et successeurs ont aussi quelques instructions pour accéder à la
mémoire en bits (bc par exemple, qui si ma mémoire est bonne copie dans le
flag de retenu le xième bit en partant de l'adresse donnée, x pouvant etre
à 32).
Pour ces instructions, l'ordre des bits est celui "conventionnel" : le bit
"0" est le bit de poids faible du premier octet. Là encore le little
endianess s'avère pratique.
Ce sont des instructions de manipulation de bits. Le 8051 peut
acceder a des bits individuels en memoire (pour une partie de
celle-ci) sans charger le contenu dans un registre.
Dans le genre, il y a le 68000 (processeur grand boutien) qui si j'ai
bonne memoire a des instructions de manipulation de bits petit
boutiennnes et d'autres grand boutiennes (et je ne veux pas dire des
versions d'une meme instruction...)
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Il y a quelques processeurs (en fait seul le 8051 me vient a l'esprit pour le moment) qui permette d'acceder aux bits individuellement. Dans ces cas l'ordre peut avoir de l'importance.
Le 386 et successeurs ont aussi quelques instructions pour accéder à la mémoire en bits (bc par exemple, qui si ma mémoire est bonne copie dans le flag de retenu le xième bit en partant de l'adresse donnée, x pouvant etre
à 32). Pour ces instructions, l'ordre des bits est celui "conventionnel" : le bit
"0" est le bit de poids faible du premier octet. Là encore le little endianess s'avère pratique.
Ce sont des instructions de manipulation de bits. Le 8051 peut acceder a des bits individuels en memoire (pour une partie de celle-ci) sans charger le contenu dans un registre.
Dans le genre, il y a le 68000 (processeur grand boutien) qui si j'ai bonne memoire a des instructions de manipulation de bits petit boutiennnes et d'autres grand boutiennes (et je ne veux pas dire des versions d'une meme instruction...)
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Yves ROMAN
Emmanuel Delahaye a écrit:
Yves ROMAN wrote on 22/10/04 :
Désolé, mais je n'arrive jamais à me souvenir du sens de big/little endian. Alors je parle en opposition Intel/Motorola...
Bienvenu au club! Si quelqu'un a un moyen mnémotechnique, qu'il le dise! Intel / Little, il me semble que les lettres en commun sont
suffisantes. Ensuite, ce n'est pas un "truc", mais on peut soit mémoriser "little end first, c.à.d. que les poids faibles sont écrits en premier. Mais bien sûr, pourquoi first et pas last? En fait, j'ai lu que le mnémonitechnique US est "Little[Big] End In", mais la subtilité de ce "In" m'échappe.
Si la donnée à ranger en mémoire est comme une carte perforée a mettre dans la fente, tu mets le bon coté dedans, et tu pousses ! C'est tiré par les cheveux (et un peu osé !) mais pourquoi pas...
Emmanuel Delahaye <emdel@YOURBRAnoos.fr> a écrit:
Yves ROMAN wrote on 22/10/04 :
Désolé, mais je n'arrive jamais à me souvenir du sens de big/little endian.
Alors je parle en opposition Intel/Motorola...
Bienvenu au club! Si quelqu'un a un moyen mnémotechnique, qu'il le
dise!
Intel / Little, il me semble que les lettres en commun sont
suffisantes.
Ensuite, ce n'est pas un "truc", mais on peut soit mémoriser "little
end first, c.à.d. que les poids faibles sont écrits en premier. Mais
bien sûr, pourquoi first et pas last? En fait, j'ai lu que le
mnémonitechnique US est "Little[Big] End In", mais la subtilité de ce
"In" m'échappe.
Si la donnée à ranger en mémoire est comme une carte perforée a mettre dans la
fente, tu mets le bon coté dedans, et tu pousses !
C'est tiré par les cheveux (et un peu osé !) mais pourquoi pas...
Désolé, mais je n'arrive jamais à me souvenir du sens de big/little endian. Alors je parle en opposition Intel/Motorola...
Bienvenu au club! Si quelqu'un a un moyen mnémotechnique, qu'il le dise! Intel / Little, il me semble que les lettres en commun sont
suffisantes. Ensuite, ce n'est pas un "truc", mais on peut soit mémoriser "little end first, c.à.d. que les poids faibles sont écrits en premier. Mais bien sûr, pourquoi first et pas last? En fait, j'ai lu que le mnémonitechnique US est "Little[Big] End In", mais la subtilité de ce "In" m'échappe.
Si la donnée à ranger en mémoire est comme une carte perforée a mettre dans la fente, tu mets le bon coté dedans, et tu pousses ! C'est tiré par les cheveux (et un peu osé !) mais pourquoi pas...
