Aller au contenu

[Résolu - C/C++] fwrite et les char sous windows


njoyard

Messages recommandés

hello

Dans le cadre d'un projet d'assembleur MIPS en C, j'écris un fichier binaire avec fwrite. Les blocs font 32 bits et j'utilise un tableau de 4 char pour ceci (pas d'int à cause du big endian, je dois écrire le fichier en little endian). Le problème est qu'apparemment, sous windows (dev-c++ 4.9.9.1) tout char que j'écris dans le fichier et qui vaut 10 (0x0d, '\n' sous linux quoi) est remplacé par DEUX ( :transpi: ) char, valant 10 et 13 (càd le '\n' sous windows)...

comment éviter ceci, sachant qu'il n'y a pas d'autre type byte en C ??? et ce comportement est il aussi a attendre avec gcc derniere version sous linux (j'ai pas l'occase de tester pour le moment) ?

Lien vers le commentaire
Partager sur d’autres sites

Je ne comprends pas ton problème.

Les retours à la ligne sont codés par "\n" sous linux (on est d'accord) et par "\n\r" sous windows.

Si tu veux mettre

toto
tata

dans un fichier, alors il faut mettre dans le fichiers des strings de ce genre :

char texte_nux[123456798] = "tata\ntoto\0"       // sous linux
char texte_win[987654321] = "tata\n\rtoto\0"     // sous windows

Lien vers le commentaire
Partager sur d’autres sites

mon probleme c'est que quand je fais:

FILE* f = fopen("test","w");
char* c = (char*) calloc(1, sizeof(char));
*c = 10;
if(fwrite(c, sizeof(char), 1, f) != 1) printf("AIEAIEAIE !!!\n");
fclose(f);

fwrite renvoie bien 1 pourtant j'ai 0x0d0a dans mon fichier....

de plus je suis pas tout a fait d'accord avec ce que tu dis.

avec mon mingw le comportement est différent. je pense d'ailleurs que la gestion la derriere est cheloue : le caractère '\n' en mémoire devient les deux caractères '\n' et '\r' lorsqu'il se trouve dans un stream (et inversement). la preuve: quand tu écris "\n" dans un fichier, t'as 0x0d0a; de même si tu relis 1 caractère de ce fichier, tu as '\n', et si t'en lis un deuxième t'as EOF.

cela dit sous linux avec gcc je pense que ce que tu dis est logique.

Lien vers le commentaire
Partager sur d’autres sites

bien obligé, mon 30Go qui hébergeait mdk 10.1 est décédé il y a 1 mois

et pas assez de place pour l'instant pour le réinstaller sur mes autres durs !

un truc qui me laisse plus perplexe: la fonction strdup.

avec mingw, strdup(0x0) renvoie 0x0

avec gcc, strdup(0x0) donne une seg error a cause de strlen().

je trouve que ce comportement est stupide... obligé de créer une fonction char strdupi(const char* s) return s ? strdup(s) : NULL;, c'est débile ! :byebye:

Lien vers le commentaire
Partager sur d’autres sites

Archivé

Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.

×
×
  • Créer...