Discussion :

[gdpasmini]

Bonjour a tous,

J'aimerais savoir si il est possible d'ouvrir un fichier binaire et de copier son contenu dans un tableau de short par exemple.

Ainsi chaque données de 16 bits du fichier seraient copiées dans une des cases de ce buffer...

Merci d'avance pour votre aide !

[Gruik]

Salut,

Tu peux surement utiliser fread() http://man.developpez.com/man3/fread.3.php

[Emmanuel Delahaye]

Tu peux surement utiliser fread() http://man.developpez.com/man3/fread.3.php

Indirectement. Si il s'agit de lire par bloc de 2 octets, il faut faire 2 accès (fgetc()) ou un accès de 2 bytes avec fread().

Ensuite, il faut 'assembler' les 2 bytes en mémoire (|, <<) pour en faire un mot de 16 bits. Il faut connaitre le format de l'enregisrement (le standard 'réseau' est 'MSB en tête').

Nota : Contrairement aux idées reçues, on a pas besoin de connaitre l'endianess de la cible.

[Invité]

qu'entends tu par "chaque données 16 bits", tu veux mettre 2 chars a la fois dans un short, ou ton fichier a qqchose a voir avec UNICODE ?

ce que je te propose, c'est de lire ton fichier dans un tableau de char, puis d'utiliser ceci pour passer des chars aus shorts :

Code :

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

1
2
3
4
union USwitch {
    char  _pc[TAILLE_MAX];
    short _ps[TAILLE_MAX/2];
};

une fois que tu as créé ton buffer de chars, voici l'utilisation :

Code :

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

1
2
3
4
5
6
7
char* pcFile = /* le contenu de ton fichier */;
size_t nFileSize = /* Nb d'octets du fichier */;
 
USwitch u;
memcpy(u._pc, pcFile, nFileSize);
 
//tu utilises u_ps comme tu veux maintenant

[Emmanuel Delahaye]

qu'entends tu par "chaque données 16 bits", tu veux mettre 2 chars a la fois dans un short, ou ton fichier a qqchose a voir avec UNICODE ?

ce que je te propose, c'est de lire ton fichier dans un tableau de char, puis d'utiliser ceci pour passer des chars aus shorts :

Code :

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

1
2
3
4
union USwitch {
    char  _pc[TAILLE_MAX];
    short _ps[TAILLE_MAX/2];
};

Pas portable. Probablement la pire des solutions...

[Invité]

Pas portable. Probablement la pire des solutions...

depuis quand c'est pas portable ? je veux bien des explications, car je ne te suis pas du tout.
union est défini dans le langage (donc portable). char est défini comme étant 1 octet, et short comme étant 2 octets.

la seul chose qu'on fait ici est d'interpreter un table d'octets en tableau de groupes de 2 octets...

donc OU est le probleme ?

[Emmanuel Delahaye]

depuis quand c'est pas portable ?

Depuis toujours !

je veux bien des explications, car je ne te suis pas du tout.
union est défini dans le langage

Oui.

(donc portable).

Conclusion hative ! Standard ne signifie pas portable.

char est défini comme étant 1 octet, et short comme étant 2 octets.

Ben non. Un char a au moins 8 bits et un short a une plage d'au moins -32767 à 32767.

la seul chose qu'on fait ici est d'interpreter un table d'octets en tableau de groupes de 2 octets...
donc OU est le probleme ?

L'endianess de la cible n'est pas forcément celle du fichier
La taille d'un short n'est pas forcément celle de 2 bytes.

[Invité]

je ne suis toujour pas d'accord, ,et encore une fois, tu ne donne guere d'avantage d'explication donc on n'avance pas beacoup...

Conclusion hative ! Standard ne signifie pas portable.

et c'est quoi portable ? puisque tous les compilateurs l'implémente, ou cela va t il planter ?

Ben non. Un char a au moins 8 bits et un short a une plage d'au moins -32767 à 32767.

et [-32767 ; 32767], ca ne tient pas dans 16 bits ?

La taille d'un short n'est pas forcément celle de 2 bytes.

pour moi, si le standard a dit, c'est dit... si quelqu'un implémente son propre compilateur et qu'il ne respecte pas ca, c'est son droit, mais c'est plus un compilateur C standard...

L'endianess de la cible n'est pas forcément celle du fichier

voici le seul point qui pourrait poser probleme... mais dans la mesure ou tout se passe sur la meme machine, sans échanges de mémoires, le stream est lu avec l'endianness de la cible

[Médinoc]

"au moins" signifie que ça peut être plus...

[DaZumba]

et c'est quoi portable ? puisque tous les compilateurs l'implémente, ou cela va t il planter ?

Portable, ca veut dire que le code, une fois compile, se comporte de la meme facon sur toutes les plateformes connues, et cela sans modification. Regarde la fonction system() par exemple: elle fait partie du langage C, mais la commande qu'on lui envoie depend du systeme. Standard, mais pas portable.

et [-32767 ; 32767], ca ne tient pas dans 16 bits ?

Si, mais ca tient aussi dans 32bits. Certaines machines ne peuvent adresser que des mots de 32 bits par exemple. Alors, un char fait 32 bits, un short 32 bits, et un int 32 bits. C'est pourquoi la norme du langage ne parle que de plages de valeurs, jamais de taille.

voici le seul point qui pourrait poser probleme... mais dans la mesure ou tout se passe sur la meme machine, sans échanges de mémoires, le stream est lu avec l'endianness de la cible

Il n'y a aucune garantie que le fichier a lire a ete cree par la machine qui le lit.

[gdpasmini]

ok

En tout cas, merci beaucoup pour ce debat qui m'a fait apprendre beaucoup de choses !

J'ai utilisé pour finir la fonction fread et j'ai fai la concaténation de deux char dans un short...

Je ne sais pas si tout ceci est tre portable mais ca marche sur ma machine cible et c ce qui m'importait car il n'est ps destiné a fonctionner ailleurs...

Voici le code que j'ai développé :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
fread (buffer, 1, lsize, pFile); // copie fichier vers tampon
 
   int j = 0;
 
   for(int i = 0; i < lsize; i++)
   {
          mesShort[j] = (((short)(buffer[i] << 8)& 0xff00) | buffer[i+1]);
          fprintf(f, "%c", linearToMuLaw(mesShort[j]));
          i++;
          j++;
 
   }

Merci encore !

[Ti-R]

La norme C spécifie

sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) = sizeof(size_t)

Par contre sous unix
http://www.unix.org/whitepapers/64bit.html
et sous Windows
http://msdn2.microsoft.com/en-us/library/9c3yd98k.aspx

Indique bien que "char" et "short" on bien une taille défini 8 et 16 bits.

Le problème se situe surtout sur des processeurs embarqués ou des processeurs spécifiques qui suive la norme et donc ne respecte pas cette convention plus ou moins commune des tailles de type utilisé sur nos OS pour PC (à vérifier pour Linux, pour chaque linux ).

[Emmanuel Delahaye]

et c'est quoi portable ? puisque tous les compilateurs l'implémente,

"Portable" signifie que le comportement est le même sur toutes les plateformes.

ou cela va t il planter ?

Sur les plateformes qui auront un comportement différent.

et [-32767 ; 32767], ca ne tient pas dans 16 bits ?

OK, mais ce n'est pas le problème. Un short peut très bien faire plus que 16 bits.

pour moi, si le standard a dit, c'est dit... si quelqu'un implémente son propre compilateur et qu'il ne respecte pas ca, c'est son droit, mais c'est plus un compilateur C standard...

Malheureusement, la normalisation du C c'est faite bien après son invention, et il a fallu intégrer l'existant. C'est pourquoi le standard définit précisément certains comportements. Pour d'autres, la définition exacte est laissée à la charge du compilateur. (implementation-dependent). C'est la cas pour la taille des types. Le C fixe la limite inférieure, mais pas la limite supérieure.

Si tu trouves que le C est trop compliqué, utilise des langages plus 'conçus', plus 'refléchis', comme Java ou C#.

voici le seul point qui pourrait poser probleme... mais dans la mesure ou tout se passe sur la meme machine, sans échanges de mémoires, le stream est lu avec l'endianness de la cible

Même en 'circuit fermé' comme tu le décris, il suffit parfois de changer de compilateur ou même un reglage du même compilateur pour tomber sur un problème de portabilité (par exemple, j'ai connu des compilateurs C pour 68k avec la taille de l'int reglable : 16-bit ou 32-bit).

Maintenant, tu fais ce que tu veux, mais tu es prévenu. Je n'ai pas dit que solution était incorrecte. J'ai simplement précisé qu'elle était non-portable, de façon à ce que les lecteurs ne la prennent pas comme une solution universelle.

On a le droit sur un forum de proposer des solutions non portables, du moment que c'est précisé. Or, tu ne l'avais pas fait.

[Jean-Marc.Bourguet]

La norme C spécifie

sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) = sizeof(size_t)

J'aimerais bien avoir une référence pour l'égalité finale. 6.18.3/2 donne une valeur minimale de 65535 pour SIZE_MAX qui est une des macros donnant les tailles maximales ajoutées en C99.

Le problème se situe surtout sur des processeurs embarqués ou des processeurs spécifiques qui suive la norme et donc ne respecte pas cette convention plus ou moins commune des tailles de type utilisé sur nos OS pour PC (à vérifier pour Linux, pour chaque linux ).

Il faut encore pouvoir suivre. Quand on a

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
@type size.c
#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
 
int main() {
   printf("%d\n", CHAR_BIT);
   printf("%d\n", (int)sizeof (char));
   printf("%d\n", (int)sizeof (short));
   printf("%d\n", (int)sizeof (int));
}
@run size
9
1
2
4

jouer avec des tailles 8/16/32 c'est peut-être un petit peu étrange.

[Ti-R]

jouer avec des tailles 8/16/32 c'est peut-être un petit peu étrange.

Ce qui me semble bizarre, c'est cela -> CHAR_BIT = 9
Même si rien n'empêche d'être présent.
Mais je préfère parler de 8/16/32 bits que de parler de 1,2,4 bytes sachant que comme tu l'as souligné CHAR_BIT peut être différent de 8.

Donc si je dis 8 bits, sur tout système, 8bits = 8 bits = 1 octet, si je dis 1 byte, sur tout système 1 byte n’est pas forcément égale à autre 1 byte. Tout dépend de ce qu’on souhaite faire avec bien entendu, et cela dépend du contexte surement aussi.

Sinon "erreur" de copié collé trop rapide de http://www.unix.org/whitepapers/64bit.html qui cite la norme ISO C -> ISO/IEC 9899:1990

size_t must represent the largest unsigned type supported by an implementation

[Invité]

Si tu trouves que le C est trop compliqué, utilise des langages plus 'conçus', plus 'refléchis', comme Java ou C#.

Merci, j'ai suffisemment d'expérience en C/C++ ; mais je n'ai jamais lu le standard du C, seulement celui du C++ (et en ce moment, je me tappe les 224 pages du C99 pour me faire une opinion objective du sujet...)

bon cela dit, je t'ai pas insulté avec du C# moi

bon allez, on zappe...

[Médinoc]

Il me semblait qu'un octet était toujours 8 bits (d'où son nom)...
C'est pour le byte que ce n'est pas le cas...

[Ti-R]

Il me semblait qu'un octet était toujours 8 bits (d'où son nom)...
C'est pour le byte que ce n'est pas le cas...

Oui désolé abus de langage je corrige !!

[Jean-Marc.Bourguet]

Merci, j'ai suffisemment d'expérience en C/C++ ; mais je n'ai jamais lu le standard du C, seulement celui du C++ (et en ce moment, je me tappe les 224 pages du C99 pour me faire une opinion objective du sujet...)

Que ce soit en C ou un en C++, on ne peut par lire autre chose que le dernier membre écrit (sauf quand il y a une série de membre structs ayant le même début ou on peut lire les membres initiaux communs à travers n'importe quelle membre).

[Emmanuel Delahaye]

Ce qui me semble bizarre, c'est cela -> CHAR_BIT = 9

C'est certes étrange, mais c'est possible et c'est autorisé par la norme qui dit >= 8 bits.

Mais je préfère parler de 8/16/32 bits que de parler de 1,2,4 bytes sachant que comme tu l'as souligné CHAR_BIT peut être différent de 8.

Ben non. Il faut parler en plage de valeurs. Justement, parce qu'un char ne fait pas forcément 8 bits. (J'ai connu des DSP avec des char de 16-bits, voire de 32).