j'ai un fichier provenant d'un programme externe que je dois parser en C.
 
en gros dans le fichier ya "tata<CR>titi<CR>toto" ou <CR> est le retour de ligne (13 en decimal, 0d en hexa).
 
je fais en C ce code la:
 

 
a l'affichage j'ai mes <CR> qui sont manges et tu coup ca m'affiche ca:
 

 
Un peu d'aide ne serait pas de refus.
 
merci d'avance

tu veux une corde ?

1. le retour à la ligne c'est #13#10 sous Windows (t'as pas précisé l'OS)
 
2. c'est quoi tes 64/71?
 
3. Et euh, si y a eu retour à la ligne (j'ai vraiment du mal a piger ton histoire), c'est que ton #13 a pas été mangé
 
Allez, racontes ;-)

1) Je ça empêche pas qu'ils sont pas dans son truc
2) 64/71 etc. c'est les codes ASCII des caractères
3) c pour ça que je lui propose une corde

 
tu ferais bien d'ouvrir ton fichier en mode binaire si tu veux faire joujou avec le codage des caracteres.
Le mode texte est la pour rendre le code C portable sous unix et windows, attention donc a ce qu'il ne te mange pas des caracteres.
 
LeGreg

MagicBuzz a écrit a écrit :   1) Je ça empêche pas qu'ils sont pas dans son truc 2) 64/71 etc. c'est les codes ASCII des caractères 3) c pour ça que je lui propose une corde

 
Ah ouai merde, j'avais pas vu le %x    
 
 

 
le fichier est deja ouvert en binaire en faisant un fopen.
 
en fait je viens de decouvir que c'est mon compilateur delorie/gcc pour dos qui ne va pas; quant a savoir si c'est un bug, je vais un peu plus me renseigner (si qq peu le faire ici, ca m'aiderait pas mal).
 
je prends ce meme code source et je le compile avec lccwin32 ca marche bien (je vois bien a l'affichage le "0d" ), par contre avec gcc 3.1 ou 2.95 ca passe pas.
 
donc je cherche un autre compilateur sous dos (dos parce que j'ai des imperatifs) en free si possible.
 

 
je ne vois pas de 'b' dans ta chaine de mode d'ouverture:

 
Au moins si tu mets le 'b', tu seras sur que le choix par défaut du compilateur sera le bon..
 
LeGreg

 
Je te remercie pour ton aide, maintenant ca a l'air de fonctionner correctement. Effectivement, il fallait "forcer" l'ouverture en binaire (chose qui a l'air d'etre faite avec lccwin32 ou gcc sous HP-UX).
 
Jusqu'a présent, je pensais (du moins ce que je faisais a la fac):
 - open -> ouverture en ascii,
 - fopen -> ouverture en binaire.
 
 

Sous Unix (et peut-être aussi sous Windows), le flag "b" n'a aucune signification. Du coup, c'est vrai qu'on a tendance à l'oublier quand on travaille habituellement sous Unix.
 

Ça n'a rien à voir. L'appel open se contente de renvoyer un descripteur de fichier sous forme d'entier, alors que fopen renvoie un descripteur de flux (type FILE), qui permet de réaliser des opérations tamponnées (et donc plus rapides).

le 'b' est justement la pour la compatibilité unix/windows.
Mais bon, on vous en voudra pas de l'oublier..
 
Ceci dit:
fopen c'est la norme ANSI (qui peut egalement fonctionner en mode non tamponné)
open sous Unix ou _open sous windows c'est la norme OS.
 
LeGreg

C'est pas normal qu'ils soient mangés !
 
Les sauts de ligne du PC sont faits de 2 caractères: 13 & 10, soit 0D 0A en hexa, ou CR+LF.
Par défaut, les fichiers sont ouvert en mode texte, ce qui convertit ces sauts doubles en simple LF.
Si ton texte vient d'une machine étrangère, et qu'il n'a qu'un simple CR ou LF, c'est peut-être ça qui le mange.
 
Solution:
-soit ouvrir avec fopen(..., "rb" );
-soit mettre au niveau global _fmode= _O_BINARY ;
Et gérer soi-même ce fichu saut !