Fichier binaire contenant 0x1A interprété comme fin de fichier
Aucune réponse
sam22
Bonjour,
Je suis un petit nouveau, mais ce forum semble efficace!
Mon problème est le suivant. J'ai trouvé un compilateur C qui fonctionne bien sous windows 8 (environnement 32/64 bits), c'est DEV-C++.
Malheureusement, je bloque sur un problème lié à la lecture d'un fichier binaire (donc contenant éventuellement n'importe quel octet, par définition). Et lorsque la suite d'octets du fichier contient un octet de valeur 0x1A (ou Ctrl-Z), il est interprété comme une fin de fichier et la lecture s'arrête, malencontreusement. J'ai essayé avec les fonctions read, fread, _read, mais c'est toujours la même chose. Enervant qu'un fichier ne puisse contenir ce caractère spécial sans que tout s'arrête. :-(
Auriez-vous une solution, en dehors de Turbo C, qui n'est vraiment pas pratique sous windows 8 (ce n'est pas un environnement natif, ou alors je n'ai pas su trouver une version tournant nativement sous ce système) ?
Merci de votre aide, car je ne m'en sors pas!
Bonne soirée
Christian
P.S. J'aurais sans doute dû aussi expliciter davantage l'histoire des structures que je n'ai pas pu utiliser comme précédemment (avec Turbo C), à cause de l'alignement automatique effectué par le nouveau compilo sur une frontière de mot, dès qu'il y a un "long" par ex. qui n'est pas aligné (exemple char tab[3], suivi d'un "long". Dans une structure, le long est aligné sur le 4ème octet, malheureusement dans le cas qui me concerne).
Oui, c'est normal. Sur tous les processeurs recents, les acces non alignes coutent tres cher (la memoire est organisee par mot de 32 bits ou plus). Et de ce point de vue, l'archi classique intel est pourrie, puisqu'elle autorise quand meme les acces non alignes qui coutent la peau des fesses (alors qu'une archi decente, comme du sparc, va te jeter avec un bus error).
Si tu veux lire/ecrire des struct avec des trous dedans: - tu peux lire/ecrire champ par champ, ce qui marche pas si mal. - tu as souvent une extension dans ton compilo (__packed ou assimile) totalement non portable qui permet d'avoir des structures plus compactes (c'est normalement reserve aux interactions directes avec le hard).
Si tu veux faire des trucs vaguement perennes dans un avenir plus lointain, outre les problemes d'alignement, tu as aussi des soucis d'endianess (ordre des octets dans un mot). C'est pour ca qu'on a invente htons, ntohs, htonl, ntohl pour faire du reseau, par exemple.
Si on passe sur du flottant, ca a eu ete pire... sauf qu'aujourd'hui je pense que la majorite des archis sont IEEE754, donc une fois que tu as determine la taille de tes flottants (float, double...) ben ca va pas trop mal se passer.
Message tres resume, tu ne devrais pas avoir trop de mal a trouver plus de doc en ligne avec quelques mots cles si ca t'interesse...
In article <jsKdncuRq59hfzjLnZ2dnUU798ydnZ2d@giganews.com>,
sam22 <nospam_christian.couepel@aliceadsl.fr.invalid> wrote:
P.S. J'aurais sans doute dû aussi expliciter davantage l'histoire des structures
que je n'ai pas pu utiliser comme précédemment (avec Turbo C), à cause de
l'alignement automatique effectué par le nouveau compilo sur une frontière de
mot, dès qu'il y a un "long" par ex. qui n'est pas aligné (exemple char tab[3],
suivi d'un "long". Dans une structure, le long est aligné sur le 4ème octet,
malheureusement dans le cas qui me concerne).
Oui, c'est normal. Sur tous les processeurs recents, les acces non alignes
coutent tres cher (la memoire est organisee par mot de 32 bits ou plus).
Et de ce point de vue, l'archi classique intel est pourrie, puisqu'elle
autorise quand meme les acces non alignes qui coutent la peau des fesses
(alors qu'une archi decente, comme du sparc, va te jeter avec un bus error).
Si tu veux lire/ecrire des struct avec des trous dedans:
- tu peux lire/ecrire champ par champ, ce qui marche pas si mal.
- tu as souvent une extension dans ton compilo (__packed ou assimile)
totalement non portable qui permet d'avoir des structures plus compactes
(c'est normalement reserve aux interactions directes avec le hard).
Si tu veux faire des trucs vaguement perennes dans un avenir plus lointain,
outre les problemes d'alignement, tu as aussi des soucis d'endianess (ordre
des octets dans un mot). C'est pour ca qu'on a invente
htons, ntohs, htonl, ntohl pour faire du reseau, par exemple.
Si on passe sur du flottant, ca a eu ete pire... sauf qu'aujourd'hui je
pense que la majorite des archis sont IEEE754, donc une fois que tu as
determine la taille de tes flottants (float, double...) ben ca va pas
trop mal se passer.
Message tres resume, tu ne devrais pas avoir trop de mal a trouver plus
de doc en ligne avec quelques mots cles si ca t'interesse...
P.S. J'aurais sans doute dû aussi expliciter davantage l'histoire des structures que je n'ai pas pu utiliser comme précédemment (avec Turbo C), à cause de l'alignement automatique effectué par le nouveau compilo sur une frontière de mot, dès qu'il y a un "long" par ex. qui n'est pas aligné (exemple char tab[3], suivi d'un "long". Dans une structure, le long est aligné sur le 4ème octet, malheureusement dans le cas qui me concerne).
Oui, c'est normal. Sur tous les processeurs recents, les acces non alignes coutent tres cher (la memoire est organisee par mot de 32 bits ou plus). Et de ce point de vue, l'archi classique intel est pourrie, puisqu'elle autorise quand meme les acces non alignes qui coutent la peau des fesses (alors qu'une archi decente, comme du sparc, va te jeter avec un bus error).
Si tu veux lire/ecrire des struct avec des trous dedans: - tu peux lire/ecrire champ par champ, ce qui marche pas si mal. - tu as souvent une extension dans ton compilo (__packed ou assimile) totalement non portable qui permet d'avoir des structures plus compactes (c'est normalement reserve aux interactions directes avec le hard).
Si tu veux faire des trucs vaguement perennes dans un avenir plus lointain, outre les problemes d'alignement, tu as aussi des soucis d'endianess (ordre des octets dans un mot). C'est pour ca qu'on a invente htons, ntohs, htonl, ntohl pour faire du reseau, par exemple.
Si on passe sur du flottant, ca a eu ete pire... sauf qu'aujourd'hui je pense que la majorite des archis sont IEEE754, donc une fois que tu as determine la taille de tes flottants (float, double...) ben ca va pas trop mal se passer.
Message tres resume, tu ne devrais pas avoir trop de mal a trouver plus de doc en ligne avec quelques mots cles si ca t'interesse...
sam22
Le lundi 25 Janvier 2016 à 19:52 par espie :
In article sam22
P.S. J'aurais sans doute dû aussi expliciter davantage l'histoire des structures que je n'ai pas pu utiliser comme précédemment (avec Turbo C), à cause de l'alignement automatique effectué par le nouveau compilo sur une frontière de mot, dès qu'il y a un "long" par ex. qui n'est pas aligné (exemple char tab[3], suivi d'un "long". Dans une structure, le long est aligné sur le 4ème octet, malheureusement dans le cas qui me concerne).
Oui, c'est normal. Sur tous les processeurs recents, les acces non alignes coutent tres cher (la memoire est organisee par mot de 32 bits ou plus). Et de ce point de vue, l'archi classique intel est pourrie, puisqu'elle autorise quand meme les acces non alignes qui coutent la peau des fesses (alors qu'une archi decente, comme du sparc, va te jeter avec un bus error).
Si tu veux lire/ecrire des struct avec des trous dedans: - tu peux lire/ecrire champ par champ, ce qui marche pas si mal. - tu as souvent une extension dans ton compilo (__packed ou assimile) totalement non portable qui permet d'avoir des structures plus compactes (c'est normalement reserve aux interactions directes avec le hard).
Si tu veux faire des trucs vaguement perennes dans un avenir plus lointain, outre les problemes d'alignement, tu as aussi des soucis d'endianess (ordre des octets dans un mot). C'est pour ca qu'on a invente htons, ntohs, htonl, ntohl pour faire du reseau, par exemple.
Si on passe sur du flottant, ca a eu ete pire... sauf qu'aujourd'hui je pense que la majorite des archis sont IEEE754, donc une fois que tu as determine la taille de tes flottants (float, double...) ben ca va pas trop mal se passer.
Message tres resume, tu ne devrais pas avoir trop de mal a trouver plus de doc en ligne avec quelques mots cles si ca t'interesse...
Bonjour, Merci! Mon compilo ne semble pas connaître l'option "packed" ou "_packed". J'ai pris l'option de lire ou écrire terme par terme. Effectivement, ça marche bien, même si la "structure" (struct) ne sert plus vraiment en tant que telle, en tout cas pour l'utilisation que j'en fais. Pour la compréhension de la structure du fichier binaire, peut-être, sans doute...
Le lundi 25 Janvier 2016 à 19:52 par espie :
In article
sam22
P.S. J'aurais sans doute dû aussi expliciter davantage l'histoire des
structures
que je n'ai pas pu utiliser comme précédemment (avec Turbo C),
à cause de
l'alignement automatique effectué par le nouveau compilo sur une
frontière de
mot, dès qu'il y a un "long" par ex. qui n'est pas
aligné (exemple char tab[3],
suivi d'un "long". Dans une structure, le long est aligné sur
le 4ème octet,
malheureusement dans le cas qui me concerne).
Oui, c'est normal. Sur tous les processeurs recents, les acces non alignes
coutent tres cher (la memoire est organisee par mot de 32 bits ou plus).
Et de ce point de vue, l'archi classique intel est pourrie, puisqu'elle
autorise quand meme les acces non alignes qui coutent la peau des fesses
(alors qu'une archi decente, comme du sparc, va te jeter avec un bus error).
Si tu veux lire/ecrire des struct avec des trous dedans:
- tu peux lire/ecrire champ par champ, ce qui marche pas si mal.
- tu as souvent une extension dans ton compilo (__packed ou assimile)
totalement non portable qui permet d'avoir des structures plus compactes
(c'est normalement reserve aux interactions directes avec le hard).
Si tu veux faire des trucs vaguement perennes dans un avenir plus lointain,
outre les problemes d'alignement, tu as aussi des soucis d'endianess (ordre
des octets dans un mot). C'est pour ca qu'on a invente
htons, ntohs, htonl, ntohl pour faire du reseau, par exemple.
Si on passe sur du flottant, ca a eu ete pire... sauf qu'aujourd'hui je
pense que la majorite des archis sont IEEE754, donc une fois que tu as
determine la taille de tes flottants (float, double...) ben ca va pas
trop mal se passer.
Message tres resume, tu ne devrais pas avoir trop de mal a trouver plus
de doc en ligne avec quelques mots cles si ca t'interesse...
Bonjour,
Merci!
Mon compilo ne semble pas connaître l'option "packed" ou "_packed".
J'ai pris l'option de lire ou écrire terme par terme. Effectivement, ça marche bien, même si la "structure" (struct) ne sert plus vraiment en tant que telle, en tout cas pour l'utilisation que j'en fais.
Pour la compréhension de la structure du fichier binaire, peut-être, sans doute...
P.S. J'aurais sans doute dû aussi expliciter davantage l'histoire des structures que je n'ai pas pu utiliser comme précédemment (avec Turbo C), à cause de l'alignement automatique effectué par le nouveau compilo sur une frontière de mot, dès qu'il y a un "long" par ex. qui n'est pas aligné (exemple char tab[3], suivi d'un "long". Dans une structure, le long est aligné sur le 4ème octet, malheureusement dans le cas qui me concerne).
Oui, c'est normal. Sur tous les processeurs recents, les acces non alignes coutent tres cher (la memoire est organisee par mot de 32 bits ou plus). Et de ce point de vue, l'archi classique intel est pourrie, puisqu'elle autorise quand meme les acces non alignes qui coutent la peau des fesses (alors qu'une archi decente, comme du sparc, va te jeter avec un bus error).
Si tu veux lire/ecrire des struct avec des trous dedans: - tu peux lire/ecrire champ par champ, ce qui marche pas si mal. - tu as souvent une extension dans ton compilo (__packed ou assimile) totalement non portable qui permet d'avoir des structures plus compactes (c'est normalement reserve aux interactions directes avec le hard).
Si tu veux faire des trucs vaguement perennes dans un avenir plus lointain, outre les problemes d'alignement, tu as aussi des soucis d'endianess (ordre des octets dans un mot). C'est pour ca qu'on a invente htons, ntohs, htonl, ntohl pour faire du reseau, par exemple.
Si on passe sur du flottant, ca a eu ete pire... sauf qu'aujourd'hui je pense que la majorite des archis sont IEEE754, donc une fois que tu as determine la taille de tes flottants (float, double...) ben ca va pas trop mal se passer.
Message tres resume, tu ne devrais pas avoir trop de mal a trouver plus de doc en ligne avec quelques mots cles si ca t'interesse...
Bonjour, Merci! Mon compilo ne semble pas connaître l'option "packed" ou "_packed". J'ai pris l'option de lire ou écrire terme par terme. Effectivement, ça marche bien, même si la "structure" (struct) ne sert plus vraiment en tant que telle, en tout cas pour l'utilisation que j'en fais. Pour la compréhension de la structure du fichier binaire, peut-être, sans doute...
