taille des variables

Bonjour,

je désire lire les caractéristiques d'un fichier WAV. Son entête est constitué de différents champs de 2 ou 4 octets que je vais mettre dans un struct.

Je suis sous Visual c++ 2005 et je compte prendre des int pour les champs de 4 octets et des shorts pour les champs de 2 octets.

Cependant, la taille des int et des short n'est pas garantie selon les compilateurs il me semble. N'existe-t-il pas un moyen permettant la portabilité de la taille des données d'un compilateur à un autre?

Ne puis-je pas avoir recours à size_t ou quelque chose de ce genre?

Merci

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

tu peut l'utiliser pour manipuler les données.

merci, mais ça ne marche pas: ces types ne sont pas reconnus à la compilation

En C99, il y a les types int8_t, int16_t, int32_t qui sont déclarés dans stdint.h. Je ne sais pas si ces types de données sont disponibles avec le compilateur de Microsoft qui n'implante pas C99 (je ne sais pas si cela a changé).

Pour garantir un entier représenté sur 4 octets, un long fait l'affaire.

Thierry

Citation:

---

Envoyé par Thierry Chappuis

Pour garantir un entier représenté sur 4 octets, un long fait l'affaire.

---

Les long sont garantis faire au moins 32 bits, pas exactement. J'ai déjà utilisé une implémentation avec des long de 36 bits, et j'utilise souvent une qui a des long de 64 bits.

Solution: inclure <limits.h> et puis utiliser les constantes qui y sont définies pour faire des typedefs qui te conviennent ou donner un message d'erreur.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Les long sont garantis faire au moins 32 bits, pas exactement. J'ai déjà utilisé une implémentation avec des long de 36 bits, et j'utilise souvent une qui a des long de 64 bits.

Solution: inclure <limits.h> et puis utiliser les constantes qui y sont définies pour faire des typedefs qui te conviennent ou donner un message d'erreur.

---

Je propose ici d'utiliser un entier de type long pour stocker une donnée codée sur au plus 32 bits, lue à partir d'un fichier au format WAV. Si le long en question fait 36 ou 64 bits, cela nous importe peu.

Thierry

Imaginons que tu désires lire dans ton fichier, de manière portable, une donnée signée codée sur 4 octets petit boutiste selon une représentation en complément à 2. Je procéderais comme suit:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

#include <stdio.h>   long read_32bits_integer(FILE *fp, int *error) { long signed_value = 0; int err = 0;   if (fp != NULL) { unsigned char buffer[4] = {0}; unsigned long unsigned_value = 0;   if (fread(buffer, sizeof buffer, 1, fp) == 1) { size_t i;   for (i = 0; i < sizeof buffer; i++) { unsigned_value |= (buffer[i] << 8 * i); }   /* -tc- N.B. 2147483648 == 2^31 */ if (unsigned_value < 2147483648UL) /* -tc- valeur positive */ { signed_value = unsigned_value; } else /* -tc- valeur negative */ { /* -tc- Attention: il faut etre attentif aux possibilites de debordement */ signed_value = (long) (unsigned_value - 2147483648UL) - 2147483647 - 1; } } else { if (feof(fp) == 1) /* -tc- EOF */ { err = 3; } else /* -tc- Erreur de lecture */ { err = 2; } } } else { /* -tc- Erreur: argument invalide */ err = 1; }   if (error != NULL) { /* -tc- on renvoit le code d'erreur */ *error = err; }   return signed_value; }

---

Thierry

Merci pour vos réponses.

Citation:

---

En C99, il y a les types int8_t, int16_t, int32_t qui sont déclarés dans stdint.h. Je ne sais pas si ces types de données sont disponibles avec le compilateur de Microsoft qui n'implante pas C99 (je ne sais pas si cela a changé).

---

Toujours pas de stdint.h :cry:

J'ai bien regardé vos propositions pour lire des données de manière portable. Ca risque d'alourdir sérieusement un problème relativement simple à la base.
Voilà mon code actuel:

Code:

---

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

struct WAV_entete{ char ID[4]; // "RIFF" en général int TailleFichier; // taille totale du fichier en octets - 8 char IDwave[8]; // "WAVEfmt " int TailleFormat; // Nombre d'octets du descripteur de format short NumFormat; // 1 = PCM : pas de compression short NbCanaux; // 1 = mono, 2 = stéréo int FreqEch; // Fréquence d'échantillonnage en Hz int ByteParSec; // Nombre d'octets par seconde short ByteParEch; // Nombre total d'octets par échantillon (Pour tous les canaux) short BitParEch; // Nombre de bits par échantillon (pour un canal):8, 12 ou 16 char Data[4]; // "data" int NbData; // Nombre de données à suivre. };   .............   WAV_entete entete;   .............   fread(&entete,44,1,f_in); // f_in étant le fichier lu

---

Ainsi, je lis tout d'un bloc, sans faire appel à une fonction qui lit le fichier pour renseigner la structure champ par champ.

Cie,

Citation:

---

Envoyé par jackk

J'ai bien regardé vos propositions pour lire des données de manière portable. Ca risque d'alourdir sérieusement un problème

---

Ben oui, comme la norme ne donne que des valeurs minimales devant être acceptées pour un type, la portabilité impose :

- soit tu n'utilises que les types garantissant de pouvoir gérer tes valeurs,

- soit tu écris un programme sachant s'adapter en fonction du compilateur, de la cible, etc. (ce qui n'est pas toujours aussi évident qu'on veut bien le croire)

Que veux-tu dire par "je lis tout d'un bloc". Si cela signifie que tu lis sizeof (struct WAV_entete) bytes à partir de ton fichier, ce n'est pas du tout portable. L'avantage de l'approche que je te proposes est qu'elle est indépendante de ta plateforme.

Thierry

Citation:

---

Que veux-tu dire par "je lis tout d'un bloc". Si cela signifie que tu lis sizeof (struct WAV_entete) bytes à partir de ton fichier

---

Pour les fichiers WAV non compressés qui m'intéressent, l'entête est toujours de 44 octets.

Par contre, pour que ces 44 octets soient idéalement répartis dans la structure, il faut que les int fassent bien 4 octets et les short 2.

Citation:

---

Envoyé par jackk

Pour les fichiers WAV non compressés qui m'intéressent, l'entête est toujours de 44 octets.

Par contre, pour que ces 44 octets soient idéalement répartis dans la structure, il faut que les int fassent bien 4 octets et les short 2.

---

et les contraintes d'alignement? Et les problèmes de boutisme?

Thierry

Citation:

---

et les contraintes d'alignement?

---

C'est-à-dire ...?

Citation:

---

Et les problèmes de boutisme?

---

C'est vrai.

Je crois que je vais limiter mes ambitions de portabilité :(

Et avec #include <inttypes.h> ?

Citation:

---

Envoyé par valefor

Et avec #include <inttypes.h> ?

---

De toute manière, même si on utilise des types de données de taille portable comme ceux déclarés dans stdint.h, le compilateur est toujours libre d'ajouter des bits d'alignement dans une structure.

Thierry

Citation:

---

Envoyé par jackk

C'est-à-dire ...?

C'est vrai.

---

Prenons par exemple la structure suivante:

Code:

---

1 2 3 4 5

struct Data { int x; char c; int y; };

---

Sur ma machine, sizeof (struct Data) ne vaut pas 9, mais 12 à cause des contraintes d'alignement (les variables de type int sont alignées sur des adresses multiple de 4).

Thierry

Citation:

---

Envoyé par Thierry Chappuis

De toute manière, même si on utilise des types de données de taille portable comme ceux déclarés dans stdint.h, le compilateur est toujours libre d'ajouter des bits d'alignement dans une structure.

Thierry

---

C'était juste pour résoudre son problème d'include.

Citation:

---

Envoyé par Thierry Chappuis

L'avantage de l'approche que je te proposes est qu'elle est indépendante de ta plateforme.

---

A moins d'avoir loupe un truc, ta methode n'est portable que sur les architecture ou les char son codes sur un octet. Ce qui est certes relativement courant mais pas garanti non plus.

Citation:

---

Envoyé par gl

A moins d'avoir loupe un truc, ta methode n'est portable que sur les architecture ou les char son codes sur un octet. Ce qui est certes relativement courant mais pas garanti non plus.

---

A moins d'avoir de mon côté manqué quelque chose, où est-ce que je fais une supposition limitant la protabilité dans mon code?

Thierry

Citation:

---

Envoyé par Thierry Chappuis

Je propose ici d'utiliser un entier de type long pour stocker une donnée codée sur au plus 32 bits, lue à partir d'un fichier au format WAV. Si le long en question fait 36 ou 64 bits, cela nous importe peu.

---

Je le sais, je pensais bien que tu le savais, mais ta formulation prêtait à confusion. (Et moi j'ai été incomplet dans ma réponse).

Citation:

---

Envoyé par Thierry Chappuis

A moins d'avoir de mon côté manqué quelque chose, où est-ce que je fais une supposition limitant la protabilité dans mon code?

---

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é.

Citation:

---

Envoyé par Jean-Marc.Bourguet

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

Citation:

---

Envoyé par cmoibal

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

Citation:

---

Envoyé par Thierry Chappuis

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.

Citation:

---

Envoyé par Thierry Chappuis

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.

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

Thierry

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.

Citation:

---

Envoyé par Thierry Chappuis

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.

Citation:

---

Envoyé par Jean-Marc.Bourguet

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