Discussion :

[jackk]

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

[cmoibal]

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.

[jackk]

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

[Thierry Chappuis]

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

[Jean-Marc.Bourguet]

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.

[Thierry Chappuis]

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

[Thierry Chappuis]

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 C :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[jackk]

Merci pour vos réponses.

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[droggo]

Cie,

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)

[Thierry Chappuis]

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

[jackk]

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.

[Thierry Chappuis]

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

[jackk]

et les contraintes d'alignement?

C'est-à-dire ...?

Et les problèmes de boutisme?

C'est vrai.

Je crois que je vais limiter mes ambitions de portabilité

[valefor]

Et avec #include <inttypes.h> ?

[Thierry Chappuis]

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

[Thierry Chappuis]

C'est-à-dire ...?

C'est vrai.

Prenons par exemple la structure suivante:

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[valefor]

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.

[gl]

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.

[Thierry Chappuis]

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

[Jean-Marc.Bourguet]

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

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