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 ( ) 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) ?

Modifié le 5 janvier 200520 a par k-o-x

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

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.

Modifié le 4 janvier 200520 a par k-o-x

Essaye d'ouvrir ton fichier en mode binaire:

fopen("test","wb")

Par défaut les fichiers sont ouverts en mode texte et il est précisé dans la spec de fopen que la lecture et l'écriture des End Of Line peut être sujette à des conversions.

http://www.cplusplus.com/ref/cstdio/fopen.html

c'est d'la m***e !

enfin bon... résolu...

c'est d'la m***e !

enfin bon... résolu...

quelle idée de vouloir programmer sous win, aussi...

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 !

perso, je ne trouve pas, ça te permet de ne pas faire de traitement sur une chaine vide, et donc d'éviter de te poser la question "pourquoi ça marche pas alors qu'il n'y a aucune erreur".

ouais sauf que un char* nul n'est pas une chaine vide....

pour ce qui est de la chaine vide ca marche sans pb !