Discussion :

[Thierry Chappuis]

Tu supposes que les octets sont répartis un par char (plutôt que par exemple 9 par groupe de 2 mots de 36 bits -- format ayant été utilisé pour du transfert avec des machines 36 bits). C'est assez difficile de faire sans une supposition de ce genre, mais elle limite (faiblement) la portabilité.

Je croyais que c'était garanti et que fgetc(), par exemple, opérait un mapping octet->unsigned char, mais il semble que je me sois trompé. Y a-t'il un moyen de faire sans cette supposition?

Merci d'avance et meilleures salutations

Thierry

[Emmanuel Delahaye]

oui, il existe la bibliotheque types.h, qui offret les type standard ( u_int32, uint16, uint8, ... )

Uniquement en C99 et si la plateforme les supporte. Ces types sont standards C99, mais pas portables.

Et c'est pas types.h, mais <stdint.h>

http://www.opengroup.org/onlinepubs/.../stdint.h.html

[gl]

Y a-t'il un moyen de faire sans cette supposition?

Je n'en vois pas.
A ma connaissance, pour effectuer une lecture de fichier binaire, il est necessaire a un moment ou un autre de faire une supposition sur la plateforme.

Le tout c'est d'en etre conscient, de faire le choix le plus judicieux possible (en ce sens, ton choix est, a mon humble avis, plutot bon puisu'un nombre important de plateforme fonctionne de la sorte) et eventuellement d'isoler ce code dans un module specifique qui pourra facilement etre adapte lors d'un portage vers une architecture particuliere.

[Jean-Marc.Bourguet]

Je croyais que c'était garanti et que fgetc(), par exemple, opérait un mapping octet->unsigned char, mais il semble que je me sois trompé. Y a-t'il un moyen de faire sans cette supposition?

Je ne vois pas. C'est le coeur des problemes de transferts de données entre systèmes ayant des représentations réellement différentes. Le seul système à mots de 36 bits que j'ai utilisé avait des options permettant de choisir un format parmi plusieurs quand il lisait des bandes magnétiques* (j'en ai donné un, il y a avait d'autres, par exemple ignorer le 8ième bit de chaque octet et mettre 5 char de 7 bits par mots de 36 bits -- format peu pratique pour une implémentation du C mais qui était le format texte normal).

-- Jean-Marc
* Un format très répandu de bande magnétique utilisait 9 pistes, 8 de données et une de parité, les IO avec elles étaient donc intrinsèquement en octets. Les disques étaient formattés pour des mots de 36 bits et n'utilisaient pas des octets. Pour les transferts via les réseaux, voir par exemple l'option tenex dans les RFC du FTP.

[Thierry Chappuis]

Merci pour tout, Jean-Marc et gl! (J'ai vraiment encore beaucoup à apprendre dans ce domaine. Enfin, pas que dans ce domaine...)

Thierry

[jackk]

Je vous remercie tous également. C'était très instructif.

Ayant eu réponse à ma question d'origine, je pense que je peux considérer le problème comme résolu.

[Jean-Marc.Bourguet]

Merci pour tout, Jean-Marc et gl! (J'ai vraiment encore beaucoup à apprendre dans ce domaine. Enfin, pas que dans ce domaine...)

Ne t'en fait pas, l'utilité de ces choses est quand même faible.

Pour complèter ce qui a déjà été écrit, on a trois choses: un format externe logique, un format physique externe et le format interne. Si les trois sont proches (i.e. tous exprimés en terme de suites de bytes de même taille), il y a des chances d'avoir la correspondance évidente (mais pas de garantie, une implémentation qui ferait un XOR avec 0xDEADBEAF de chaque byte lu ou écrit serait conforme! et on peut imaginer des cas où la correspondance évidente n'est pas la meilleure chose à faire). Si deux d'entre eux sont éloignés (le format logique externe défini en terme d'octets, le format physique externe défini en terme de mots de 36 bits, le format interne imposé par le C exigeant des char d'au moins 8 bits recouvrant toute la mémoire ne sont pas si proches que cela l'un de l'autre, surtout les deux premiers), il va falloir faire des hypothèses sur la manière dont les choses se correspondent entre elles.

[Thierry Chappuis]

Ne t'en fait pas, l'utilité de ces choses est quand même faible.

Pour complèter ce qui a déjà été écrit, on a trois choses: un format externe logique, un format physique externe et le format interne. Si les trois sont proches (i.e. tous exprimés en terme de suites de bytes de même taille), il y a des chances d'avoir la correspondance évidente (mais pas de garantie, une implémentation qui ferait un XOR avec 0xDEADBEAF de chaque byte lu ou écrit serait conforme! et on peut imaginer des cas où la correspondance évidente n'est pas la meilleure chose à faire). Si deux d'entre eux sont éloignés (le format logique externe défini en terme d'octets, le format physique externe défini en terme de mots de 36 bits, le format interne imposé par le C exigeant des char d'au moins 8 bits recouvrant toute la mémoire ne sont pas si proche que cela l'un de l'autres, surtout les deux premiers), il va falloir faire des hypothèses sur la manière dont les choses se correspondent entre elles.

Merci!

Thierry