J'ai un petit problème avec la taille des structures contenant des char :
typedef struct {
unsigned char c1;
unsigned char c2;
} MaStruct;
un sizeof(MaStruct) renvoie 4 et non le 2 attentu... ce qui me pose
problème
pour lire un fichier dont l'entête commence par des informations codées
sur
un octet (et je n'ai évidement pas envie de lire chaque info une à une).
Comment résoudre ou détourner ce problème ?
J'ai un petit problème avec la taille des structures contenant des char :
typedef struct {
unsigned char c1;
unsigned char c2;
} MaStruct;
un sizeof(MaStruct) renvoie 4 et non le 2 attentu... ce qui me pose
problème
pour lire un fichier dont l'entête commence par des informations codées
sur
un octet (et je n'ai évidement pas envie de lire chaque info une à une).
Comment résoudre ou détourner ce problème ?
J'ai un petit problème avec la taille des structures contenant des char :
typedef struct {
unsigned char c1;
unsigned char c2;
} MaStruct;
un sizeof(MaStruct) renvoie 4 et non le 2 attentu... ce qui me pose
problème
pour lire un fichier dont l'entête commence par des informations codées
sur
un octet (et je n'ai évidement pas envie de lire chaque info une à une).
Comment résoudre ou détourner ce problème ?
Non seulement un int
(voire un char) n'a pas forcément la même taille d'une architecture à
l'autre (problème cependant facilement résolvable en C99 avec
int8_t...),
Non seulement un int
(voire un char) n'a pas forcément la même taille d'une architecture à
l'autre (problème cependant facilement résolvable en C99 avec
int8_t...),
Non seulement un int
(voire un char) n'a pas forcément la même taille d'une architecture à
l'autre (problème cependant facilement résolvable en C99 avec
int8_t...),
Je dois etre fatigue mais c'est interessant. Oui sizeof(char) =1, mais
prenons un (unsigned) char sur par exemple 12 bits,
apres un fread() de 1 char ou un fgetc(), ca va bien pointer un byte
soit 12 bits plus loin, non ?
Je dois etre fatigue mais c'est interessant. Oui sizeof(char) =1, mais
prenons un (unsigned) char sur par exemple 12 bits,
apres un fread() de 1 char ou un fgetc(), ca va bien pointer un byte
soit 12 bits plus loin, non ?
Je dois etre fatigue mais c'est interessant. Oui sizeof(char) =1, mais
prenons un (unsigned) char sur par exemple 12 bits,
apres un fread() de 1 char ou un fgetc(), ca va bien pointer un byte
soit 12 bits plus loin, non ?
Non, aucun risque. Le mécanisme interne de lecture de flux est sur 8
bits quoiqu'il arrive.
Ce n'est pas dépendant de l'implémentation (même si en pratique,
c'est actuellement toujours 8 bits)?
Non, aucun risque. Le mécanisme interne de lecture de flux est sur 8
bits quoiqu'il arrive.
Ce n'est pas dépendant de l'implémentation (même si en pratique,
c'est actuellement toujours 8 bits)?
Non, aucun risque. Le mécanisme interne de lecture de flux est sur 8
bits quoiqu'il arrive.
Ce n'est pas dépendant de l'implémentation (même si en pratique,
c'est actuellement toujours 8 bits)?
Donc, si je comprends ces paroles, pour ce programme :
#include <stdio.h>
int main(void) {
FILE *f;
unsigned char wdata = -1;
unsigned char rdata = 0;
f = fopen("test.dat", "wb");
fwrite(&wdata, 1, 1, f);
fclose(f);
f = fopen("test.dat", "rb");
fread(&rdata, 1, 1, f);
fclose(f);
printf("ecrit: %d, lu = %dn", wdata, rdata);
return 0;
}
dans l'hypothèse où toutes les I/O fonctionnent, on doit avoir, sur une
implémentation où CHAR_BITS vaut 12, l'affichage suivant :
ecrit: 4095, lu = 255
Or j'ai cru comprendre, dans ce que dit la norme, que ce qui est lu doit
être égal à ce qui a été écrit par la même implémentation :
7.19.2 Streams
[#3] A binary stream is an ordered sequence of characters
that can transparently record internal data. Data read in
from a binary stream shall compare equal to the data that
were earlier written out to that stream, under the same
implementation. [...]
Donc on devrait plutôt avoir :
ecrit: 4095, lu = 4095
Non ?
Donc, si je comprends ces paroles, pour ce programme :
#include <stdio.h>
int main(void) {
FILE *f;
unsigned char wdata = -1;
unsigned char rdata = 0;
f = fopen("test.dat", "wb");
fwrite(&wdata, 1, 1, f);
fclose(f);
f = fopen("test.dat", "rb");
fread(&rdata, 1, 1, f);
fclose(f);
printf("ecrit: %d, lu = %dn", wdata, rdata);
return 0;
}
dans l'hypothèse où toutes les I/O fonctionnent, on doit avoir, sur une
implémentation où CHAR_BITS vaut 12, l'affichage suivant :
ecrit: 4095, lu = 255
Or j'ai cru comprendre, dans ce que dit la norme, que ce qui est lu doit
être égal à ce qui a été écrit par la même implémentation :
7.19.2 Streams
[#3] A binary stream is an ordered sequence of characters
that can transparently record internal data. Data read in
from a binary stream shall compare equal to the data that
were earlier written out to that stream, under the same
implementation. [...]
Donc on devrait plutôt avoir :
ecrit: 4095, lu = 4095
Non ?
Donc, si je comprends ces paroles, pour ce programme :
#include <stdio.h>
int main(void) {
FILE *f;
unsigned char wdata = -1;
unsigned char rdata = 0;
f = fopen("test.dat", "wb");
fwrite(&wdata, 1, 1, f);
fclose(f);
f = fopen("test.dat", "rb");
fread(&rdata, 1, 1, f);
fclose(f);
printf("ecrit: %d, lu = %dn", wdata, rdata);
return 0;
}
dans l'hypothèse où toutes les I/O fonctionnent, on doit avoir, sur une
implémentation où CHAR_BITS vaut 12, l'affichage suivant :
ecrit: 4095, lu = 255
Or j'ai cru comprendre, dans ce que dit la norme, que ce qui est lu doit
être égal à ce qui a été écrit par la même implémentation :
7.19.2 Streams
[#3] A binary stream is an ordered sequence of characters
that can transparently record internal data. Data read in
from a binary stream shall compare equal to the data that
were earlier written out to that stream, under the same
implementation. [...]
Donc on devrait plutôt avoir :
ecrit: 4095, lu = 4095
Non ?
In 'fr.comp.lang.c', Alexandre BACQUART wrote:Non seulement un int
(voire un char) n'a pas forcément la même taille d'une architecture à
l'autre (problème cependant facilement résolvable en C99 avec
int8_t...),
C'est pas vrai.
Le langage C99 n'a pas le pouvoir de créer des types
nouveaux sur des architectures qui ne peuvent pas les implémenter
(Sur un DSP TMS320C64, il *n'existe pas* d'objets < 16 bits). Dans sa
grande sagesse (et celle des rédacteurs), le langage C99 *n'impose
pas* les types à taille fixe. Il dit simplement que *sur les
architectures qui l'acceptent*, l'implémenteur a le droit de définir
des types à taille fixe.
Ces types sont donc par nature non portables
(leur existence même dépend de l'architecture), et pour moi, n'ont
*aucun* intéret.
Au moins, un char, c'est un char, et je me f*us pas mal qu'il fasse 8
ou 128 bits.
Les types 'at_least' (int_least<bits>_t) me paraissent plus
intelligents, mais ils n'apportent rien sur le plan sémantique par
rapport aux types existants (à part pour les grands entiers, 64 ou
128 bits).
Tout programmeur C muni d'un cerveau en état de marche
sait qu'un char est un 'at_least8', un short et un int un
'at_least16' et un long un 'at_least32'.
In 'fr.comp.lang.c', Alexandre BACQUART <tek512@hotmail.com> wrote:
Non seulement un int
(voire un char) n'a pas forcément la même taille d'une architecture à
l'autre (problème cependant facilement résolvable en C99 avec
int8_t...),
C'est pas vrai.
Le langage C99 n'a pas le pouvoir de créer des types
nouveaux sur des architectures qui ne peuvent pas les implémenter
(Sur un DSP TMS320C64, il *n'existe pas* d'objets < 16 bits). Dans sa
grande sagesse (et celle des rédacteurs), le langage C99 *n'impose
pas* les types à taille fixe. Il dit simplement que *sur les
architectures qui l'acceptent*, l'implémenteur a le droit de définir
des types à taille fixe.
Ces types sont donc par nature non portables
(leur existence même dépend de l'architecture), et pour moi, n'ont
*aucun* intéret.
Au moins, un char, c'est un char, et je me f*us pas mal qu'il fasse 8
ou 128 bits.
Les types 'at_least' (int_least<bits>_t) me paraissent plus
intelligents, mais ils n'apportent rien sur le plan sémantique par
rapport aux types existants (à part pour les grands entiers, 64 ou
128 bits).
Tout programmeur C muni d'un cerveau en état de marche
sait qu'un char est un 'at_least8', un short et un int un
'at_least16' et un long un 'at_least32'.
In 'fr.comp.lang.c', Alexandre BACQUART wrote:Non seulement un int
(voire un char) n'a pas forcément la même taille d'une architecture à
l'autre (problème cependant facilement résolvable en C99 avec
int8_t...),
C'est pas vrai.
Le langage C99 n'a pas le pouvoir de créer des types
nouveaux sur des architectures qui ne peuvent pas les implémenter
(Sur un DSP TMS320C64, il *n'existe pas* d'objets < 16 bits). Dans sa
grande sagesse (et celle des rédacteurs), le langage C99 *n'impose
pas* les types à taille fixe. Il dit simplement que *sur les
architectures qui l'acceptent*, l'implémenteur a le droit de définir
des types à taille fixe.
Ces types sont donc par nature non portables
(leur existence même dépend de l'architecture), et pour moi, n'ont
*aucun* intéret.
Au moins, un char, c'est un char, et je me f*us pas mal qu'il fasse 8
ou 128 bits.
Les types 'at_least' (int_least<bits>_t) me paraissent plus
intelligents, mais ils n'apportent rien sur le plan sémantique par
rapport aux types existants (à part pour les grands entiers, 64 ou
128 bits).
Tout programmeur C muni d'un cerveau en état de marche
sait qu'un char est un 'at_least8', un short et un int un
'at_least16' et un long un 'at_least32'.
In 'fr.comp.lang.c', "Régis Troadec" wrote:Je dois etre fatigue mais c'est interessant. Oui sizeof(char) =1, mais
prenons un (unsigned) char sur par exemple 12 bits,
apres un fread() de 1 char ou un fgetc(), ca va bien pointer un byte
soit 12 bits plus loin, non ?
Il n'y a pas de 'bits en trop' dans les fichiers. Le bytes de flux font 8
bits (on peut même prononcer le mot maudit "octets"). Ces 8 bits rentrent
dans n'importe quel char qu'il fasse 8 ou 256 bits. C'est probablement pour
ça qu'un char doit faire 8 bits *minimum*.
Dans l'autre sens, seuls les 8 bits de poids faible seront écrits dans le
byte du flux.
In 'fr.comp.lang.c', "Régis Troadec" <regt@wanadoo.fr> wrote:
Je dois etre fatigue mais c'est interessant. Oui sizeof(char) =1, mais
prenons un (unsigned) char sur par exemple 12 bits,
apres un fread() de 1 char ou un fgetc(), ca va bien pointer un byte
soit 12 bits plus loin, non ?
Il n'y a pas de 'bits en trop' dans les fichiers. Le bytes de flux font 8
bits (on peut même prononcer le mot maudit "octets"). Ces 8 bits rentrent
dans n'importe quel char qu'il fasse 8 ou 256 bits. C'est probablement pour
ça qu'un char doit faire 8 bits *minimum*.
Dans l'autre sens, seuls les 8 bits de poids faible seront écrits dans le
byte du flux.
In 'fr.comp.lang.c', "Régis Troadec" wrote:Je dois etre fatigue mais c'est interessant. Oui sizeof(char) =1, mais
prenons un (unsigned) char sur par exemple 12 bits,
apres un fread() de 1 char ou un fgetc(), ca va bien pointer un byte
soit 12 bits plus loin, non ?
Il n'y a pas de 'bits en trop' dans les fichiers. Le bytes de flux font 8
bits (on peut même prononcer le mot maudit "octets"). Ces 8 bits rentrent
dans n'importe quel char qu'il fasse 8 ou 256 bits. C'est probablement pour
ça qu'un char doit faire 8 bits *minimum*.
Dans l'autre sens, seuls les 8 bits de poids faible seront écrits dans le
byte du flux.
Les bytes des flux font toujours 8 bits (rien à voir avec le C).
Les bytes des flux font toujours 8 bits (rien à voir avec le C).
Les bytes des flux font toujours 8 bits (rien à voir avec le C).
le C dit que un char fait au moins 8 bits (donc un prog portable ne
doit pas utiliser les autres bits)...
cela me parait logique que les fonctions portables fputc()/fgetc() ne
voient que les 8 premiers bits des char... non ?
le C dit que un char fait au moins 8 bits (donc un prog portable ne
doit pas utiliser les autres bits)...
cela me parait logique que les fonctions portables fputc()/fgetc() ne
voient que les 8 premiers bits des char... non ?
le C dit que un char fait au moins 8 bits (donc un prog portable ne
doit pas utiliser les autres bits)...
cela me parait logique que les fonctions portables fputc()/fgetc() ne
voient que les 8 premiers bits des char... non ?
Les bytes des flux font toujours 8 bits (rien à voir avec le C).
En effet cela n'a rien à voir avec les flux ("streams") du C. Ceux-là
sont soit basés sur des char, soit basé sur des wchar_t (selon leur
orientation, cf fwide() et en général <wchar.h>).
Un autre concept existant en C est celui de fichier associé au flux.
Ceux-ci peuvent parfaitement être basés sur des unités de taille plus
grandes ou plus petites. Un exemple clairement énoncé par la norme est
la possibilité d'avoir un flux élargi associé à un fichier de
"multibytes élargis" où le code 0 est possible sans signifier ' ', ce
qui suggère clairement la possibilité d'une implémentation de stdio qui
manipulent des fichiers textes encodés en UTF-16.
Les bytes des flux font toujours 8 bits (rien à voir avec le C).
En effet cela n'a rien à voir avec les flux ("streams") du C. Ceux-là
sont soit basés sur des char, soit basé sur des wchar_t (selon leur
orientation, cf fwide() et en général <wchar.h>).
Un autre concept existant en C est celui de fichier associé au flux.
Ceux-ci peuvent parfaitement être basés sur des unités de taille plus
grandes ou plus petites. Un exemple clairement énoncé par la norme est
la possibilité d'avoir un flux élargi associé à un fichier de
"multibytes élargis" où le code 0 est possible sans signifier ' ', ce
qui suggère clairement la possibilité d'une implémentation de stdio qui
manipulent des fichiers textes encodés en UTF-16.
Les bytes des flux font toujours 8 bits (rien à voir avec le C).
En effet cela n'a rien à voir avec les flux ("streams") du C. Ceux-là
sont soit basés sur des char, soit basé sur des wchar_t (selon leur
orientation, cf fwide() et en général <wchar.h>).
Un autre concept existant en C est celui de fichier associé au flux.
Ceux-ci peuvent parfaitement être basés sur des unités de taille plus
grandes ou plus petites. Un exemple clairement énoncé par la norme est
la possibilité d'avoir un flux élargi associé à un fichier de
"multibytes élargis" où le code 0 est possible sans signifier ' ', ce
qui suggère clairement la possibilité d'une implémentation de stdio qui
manipulent des fichiers textes encodés en UTF-16.
