Bonjour.
Je suis peu habitué à manipuler des fichiers en lecture/écriture, e t
je me trouve avec un code qui produit un résultat différent suivant
qu'il est compilé et exécuté sous Ubuntu et GCC ou Windows et MingW .
#include <stdio.h>
#include <stdlib.h>
FILE *xfopen(char const *path, const char *mode)
{
FILE *fp = fopen(path, mode);
if(fp == NULL)
{
perror("xfopen ");
exit(EXIT_FAILURE);
}
return fp;
}
int read_int(FILE *fp)
{
int ret;
if(fread(&ret, sizeof(int), 1, fp) < 1)
{
fprintf(stderr, "Error: read_int");
exit(EXIT_FAILURE);
}
return ret;
}
void write_int(FILE *fp, int n)
{
if(fwrite(&n, sizeof(int), 1, fp) < 1)
{
fprintf(stderr, "Error : write_int");
exit(EXIT_FAILURE);
}
}
int main(void)
{
int i, n;
char const *filename = "test.txt";
FILE *fp = NULL;
/* write */
fp = xfopen(filename, "w");
for(i = 0; i < 3; i++)
write_int(fp, i);
fclose(fp); /* 1 2 3 */
/* read / write */
fp = xfopen(filename, "rb+");
n = read_int(fp);
printf("n = %dn", n);
write_int(fp, n + 10);
fclose(fp); /* 1 11 3 */
/* read */
fp = xfopen(filename, "r");
for(i = 0; i < 3; i++)
printf("%dn", read_int(fp));
fclose(fp);
return 0;
}
Je commence par écrire 3 entiers dans un fichier.
J'ouvre une deuxième fois le fichier en mode rb+, je lis le premier
entier, et j'écris à la suite.
Problème, sous Ubuntu, cette écriture fonctionne bien, et l'affichage
du contenu du fichier me donne bien 1, 11, 3, qui est le résultat
attendu.
Sous Windows par contre, le fichier contient toujours 1, 2, 3.
J'ai fait quelques tests avec ftell entre la lecture et l'écriture, et
la valeur retournée est normale(la taille d'un entier).
Une explication?
Merci d'avance.
Bonjour.
Je suis peu habitué à manipuler des fichiers en lecture/écriture, e t
je me trouve avec un code qui produit un résultat différent suivant
qu'il est compilé et exécuté sous Ubuntu et GCC ou Windows et MingW .
#include <stdio.h>
#include <stdlib.h>
FILE *xfopen(char const *path, const char *mode)
{
FILE *fp = fopen(path, mode);
if(fp == NULL)
{
perror("xfopen ");
exit(EXIT_FAILURE);
}
return fp;
}
int read_int(FILE *fp)
{
int ret;
if(fread(&ret, sizeof(int), 1, fp) < 1)
{
fprintf(stderr, "Error: read_int");
exit(EXIT_FAILURE);
}
return ret;
}
void write_int(FILE *fp, int n)
{
if(fwrite(&n, sizeof(int), 1, fp) < 1)
{
fprintf(stderr, "Error : write_int");
exit(EXIT_FAILURE);
}
}
int main(void)
{
int i, n;
char const *filename = "test.txt";
FILE *fp = NULL;
/* write */
fp = xfopen(filename, "w");
for(i = 0; i < 3; i++)
write_int(fp, i);
fclose(fp); /* 1 2 3 */
/* read / write */
fp = xfopen(filename, "rb+");
n = read_int(fp);
printf("n = %dn", n);
write_int(fp, n + 10);
fclose(fp); /* 1 11 3 */
/* read */
fp = xfopen(filename, "r");
for(i = 0; i < 3; i++)
printf("%dn", read_int(fp));
fclose(fp);
return 0;
}
Je commence par écrire 3 entiers dans un fichier.
J'ouvre une deuxième fois le fichier en mode rb+, je lis le premier
entier, et j'écris à la suite.
Problème, sous Ubuntu, cette écriture fonctionne bien, et l'affichage
du contenu du fichier me donne bien 1, 11, 3, qui est le résultat
attendu.
Sous Windows par contre, le fichier contient toujours 1, 2, 3.
J'ai fait quelques tests avec ftell entre la lecture et l'écriture, et
la valeur retournée est normale(la taille d'un entier).
Une explication?
Merci d'avance.
Bonjour.
Je suis peu habitué à manipuler des fichiers en lecture/écriture, e t
je me trouve avec un code qui produit un résultat différent suivant
qu'il est compilé et exécuté sous Ubuntu et GCC ou Windows et MingW .
#include <stdio.h>
#include <stdlib.h>
FILE *xfopen(char const *path, const char *mode)
{
FILE *fp = fopen(path, mode);
if(fp == NULL)
{
perror("xfopen ");
exit(EXIT_FAILURE);
}
return fp;
}
int read_int(FILE *fp)
{
int ret;
if(fread(&ret, sizeof(int), 1, fp) < 1)
{
fprintf(stderr, "Error: read_int");
exit(EXIT_FAILURE);
}
return ret;
}
void write_int(FILE *fp, int n)
{
if(fwrite(&n, sizeof(int), 1, fp) < 1)
{
fprintf(stderr, "Error : write_int");
exit(EXIT_FAILURE);
}
}
int main(void)
{
int i, n;
char const *filename = "test.txt";
FILE *fp = NULL;
/* write */
fp = xfopen(filename, "w");
for(i = 0; i < 3; i++)
write_int(fp, i);
fclose(fp); /* 1 2 3 */
/* read / write */
fp = xfopen(filename, "rb+");
n = read_int(fp);
printf("n = %dn", n);
write_int(fp, n + 10);
fclose(fp); /* 1 11 3 */
/* read */
fp = xfopen(filename, "r");
for(i = 0; i < 3; i++)
printf("%dn", read_int(fp));
fclose(fp);
return 0;
}
Je commence par écrire 3 entiers dans un fichier.
J'ouvre une deuxième fois le fichier en mode rb+, je lis le premier
entier, et j'écris à la suite.
Problème, sous Ubuntu, cette écriture fonctionne bien, et l'affichage
du contenu du fichier me donne bien 1, 11, 3, qui est le résultat
attendu.
Sous Windows par contre, le fichier contient toujours 1, 2, 3.
J'ai fait quelques tests avec ftell entre la lecture et l'écriture, et
la valeur retournée est normale(la taille d'un entier).
Une explication?
Merci d'avance.
Sous Windows par contre, le fichier contient toujours 1, 2, 3.
Sous Windows par contre, le fichier contient toujours 1, 2, 3.
Sous Windows par contre, le fichier contient toujours 1, 2, 3.
Le 29 novembre 2010, GurneyH a écrit :
> Sous Windows par contre, le fichier contient toujours 1, 2, 3.
Les droits d'accès sur test.txt sont-ils bons ?
--
LL
Le 29 novembre 2010, GurneyH a écrit :
> Sous Windows par contre, le fichier contient toujours 1, 2, 3.
Les droits d'accès sur test.txt sont-ils bons ?
--
LL
Le 29 novembre 2010, GurneyH a écrit :
> Sous Windows par contre, le fichier contient toujours 1, 2, 3.
Les droits d'accès sur test.txt sont-ils bons ?
--
LL
Je suis peu habitué à manipuler des fichiers en lecture/écriture, et
je me trouve avec un code qui produit un résultat différent suivant
qu'il est compilé et exécuté sous Ubuntu et GCC ou Windows et MingW.
Je commence par écrire 3 entiers dans un fichier.
J'ouvre une deuxième fois le fichier en mode rb+, je lis le premier
entier, et j'écris à la suite.
Problème, sous Ubuntu, cette écriture fonctionne bien, et l'affichage
du contenu du fichier me donne bien 1, 11, 3, qui est le résultat
attendu.
Sous Windows par contre, le fichier contient toujours 1, 2, 3.
Une explication?
Je suis peu habitué à manipuler des fichiers en lecture/écriture, et
je me trouve avec un code qui produit un résultat différent suivant
qu'il est compilé et exécuté sous Ubuntu et GCC ou Windows et MingW.
Je commence par écrire 3 entiers dans un fichier.
J'ouvre une deuxième fois le fichier en mode rb+, je lis le premier
entier, et j'écris à la suite.
Problème, sous Ubuntu, cette écriture fonctionne bien, et l'affichage
du contenu du fichier me donne bien 1, 11, 3, qui est le résultat
attendu.
Sous Windows par contre, le fichier contient toujours 1, 2, 3.
Une explication?
Je suis peu habitué à manipuler des fichiers en lecture/écriture, et
je me trouve avec un code qui produit un résultat différent suivant
qu'il est compilé et exécuté sous Ubuntu et GCC ou Windows et MingW.
Je commence par écrire 3 entiers dans un fichier.
J'ouvre une deuxième fois le fichier en mode rb+, je lis le premier
entier, et j'écris à la suite.
Problème, sous Ubuntu, cette écriture fonctionne bien, et l'affichage
du contenu du fichier me donne bien 1, 11, 3, qui est le résultat
attendu.
Sous Windows par contre, le fichier contient toujours 1, 2, 3.
Une explication?
GurneyH écrivit :
>> Je suis peu habitué à manipuler des fichiers en lecture/écriture , et
>> je me trouve avec un code qui produit un résultat différent suivan t
>> qu'il est compilé et exécuté sous Ubuntu et GCC ou Windows et Mi ngW.
Ta première version écrivait en texte et relisait en binaire, clairem ent
c'est un mélange des genres... mais c'est corrigé.
Cela étant, les fichiers binaires ou textes n'ont rien à voir dans to n
problème : tu obtiens exactement le même résultat avec des fichiers texte.
>> Je commence par écrire 3 entiers dans un fichier.
>> J'ouvre une deuxième fois le fichier en mode rb+, je lis le premier
>> entier, et j'écris à la suite.
>> Problème, sous Ubuntu, cette écriture fonctionne bien, et l'affich age
>> du contenu du fichier me donne bien 1, 11, 3, qui est le résultat
>> attendu.
>> Sous Windows par contre, le fichier contient toujours 1, 2, 3.
Oui, j'obtiens la même chose, y compris avec SUA (le POSIX de Windows).
Ce qui me semble une non-conformité de la part de Microsoft.
>> Une explication?
À vue de nez, l'implémentation de stdio de Microsoft ne respecte pas la
norme pour un fichier ouvert en "r+" ou "rb+" : si tu fais une lecture
suivie directement d'une écriture (sans remise-à-zéro de l'état d u
tampon), l'écriture n'est pas prise en compte au moment de fermer le
fichier, l'implémentation fait comme si le fichier était encore en mo de
lecture et ne met pas à jour le disque :-(
C'est ÀMHA non conforme : la norme précise bien que si tu fais le
contraire (écriture suivi de lecture), un programme pour être conform e
doit faire une remise-à-zéro intermédiaire : en creux, cela veut di re
que dans le sens que tu utilises, cela doit fonctionner.
En même temps, la solution est « simple » : il suffit de rajouter u ne
opération de remise-à-zéro même si c'est officiellement inutile: essaye
n = read_int(fp);
printf("n = %dn", n);
fseek(fp, 0L, SEEK_CUR); /* remise à zéro du tampon */
write_int(fp, n + 10);
Antoine
GurneyH écrivit :
>> Je suis peu habitué à manipuler des fichiers en lecture/écriture , et
>> je me trouve avec un code qui produit un résultat différent suivan t
>> qu'il est compilé et exécuté sous Ubuntu et GCC ou Windows et Mi ngW.
Ta première version écrivait en texte et relisait en binaire, clairem ent
c'est un mélange des genres... mais c'est corrigé.
Cela étant, les fichiers binaires ou textes n'ont rien à voir dans to n
problème : tu obtiens exactement le même résultat avec des fichiers texte.
>> Je commence par écrire 3 entiers dans un fichier.
>> J'ouvre une deuxième fois le fichier en mode rb+, je lis le premier
>> entier, et j'écris à la suite.
>> Problème, sous Ubuntu, cette écriture fonctionne bien, et l'affich age
>> du contenu du fichier me donne bien 1, 11, 3, qui est le résultat
>> attendu.
>> Sous Windows par contre, le fichier contient toujours 1, 2, 3.
Oui, j'obtiens la même chose, y compris avec SUA (le POSIX de Windows).
Ce qui me semble une non-conformité de la part de Microsoft.
>> Une explication?
À vue de nez, l'implémentation de stdio de Microsoft ne respecte pas la
norme pour un fichier ouvert en "r+" ou "rb+" : si tu fais une lecture
suivie directement d'une écriture (sans remise-à-zéro de l'état d u
tampon), l'écriture n'est pas prise en compte au moment de fermer le
fichier, l'implémentation fait comme si le fichier était encore en mo de
lecture et ne met pas à jour le disque :-(
C'est ÀMHA non conforme : la norme précise bien que si tu fais le
contraire (écriture suivi de lecture), un programme pour être conform e
doit faire une remise-à-zéro intermédiaire : en creux, cela veut di re
que dans le sens que tu utilises, cela doit fonctionner.
En même temps, la solution est « simple » : il suffit de rajouter u ne
opération de remise-à-zéro même si c'est officiellement inutile: essaye
n = read_int(fp);
printf("n = %dn", n);
fseek(fp, 0L, SEEK_CUR); /* remise à zéro du tampon */
write_int(fp, n + 10);
Antoine
GurneyH écrivit :
>> Je suis peu habitué à manipuler des fichiers en lecture/écriture , et
>> je me trouve avec un code qui produit un résultat différent suivan t
>> qu'il est compilé et exécuté sous Ubuntu et GCC ou Windows et Mi ngW.
Ta première version écrivait en texte et relisait en binaire, clairem ent
c'est un mélange des genres... mais c'est corrigé.
Cela étant, les fichiers binaires ou textes n'ont rien à voir dans to n
problème : tu obtiens exactement le même résultat avec des fichiers texte.
>> Je commence par écrire 3 entiers dans un fichier.
>> J'ouvre une deuxième fois le fichier en mode rb+, je lis le premier
>> entier, et j'écris à la suite.
>> Problème, sous Ubuntu, cette écriture fonctionne bien, et l'affich age
>> du contenu du fichier me donne bien 1, 11, 3, qui est le résultat
>> attendu.
>> Sous Windows par contre, le fichier contient toujours 1, 2, 3.
Oui, j'obtiens la même chose, y compris avec SUA (le POSIX de Windows).
Ce qui me semble une non-conformité de la part de Microsoft.
>> Une explication?
À vue de nez, l'implémentation de stdio de Microsoft ne respecte pas la
norme pour un fichier ouvert en "r+" ou "rb+" : si tu fais une lecture
suivie directement d'une écriture (sans remise-à-zéro de l'état d u
tampon), l'écriture n'est pas prise en compte au moment de fermer le
fichier, l'implémentation fait comme si le fichier était encore en mo de
lecture et ne met pas à jour le disque :-(
C'est ÀMHA non conforme : la norme précise bien que si tu fais le
contraire (écriture suivi de lecture), un programme pour être conform e
doit faire une remise-à-zéro intermédiaire : en creux, cela veut di re
que dans le sens que tu utilises, cela doit fonctionner.
En même temps, la solution est « simple » : il suffit de rajouter u ne
opération de remise-à-zéro même si c'est officiellement inutile: essaye
n = read_int(fp);
printf("n = %dn", n);
fseek(fp, 0L, SEEK_CUR); /* remise à zéro du tampon */
write_int(fp, n + 10);
Antoine
À vue de nez, l'implémentation de stdio de Microsoft ne respecte pas la
norme pour un fichier ouvert en "r+" ou "rb+" : si tu fais une lecture
suivie directement d'une écriture (sans remise-à-zéro de l'état d u
tampon), l'écriture n'est pas prise en compte au moment de fermer le
fichier, l'implémentation fait comme si le fichier était encore en mo de
lecture et ne met pas à jour le disque :-(
C'est ÀMHA non conforme : la norme précise bien que si tu fais le
contraire (écriture suivi de lecture), un programme pour être conform e
doit faire une remise-à-zéro intermédiaire : en creux, cela veut di re
que dans le sens que tu utilises, cela doit fonctionner.
En même temps, la solution est « simple » : il suffit de rajouter u ne
opération de remise-à-zéro même si c'est officiellement inutile: essaye
n = read_int(fp);
printf("n = %dn", n);
fseek(fp, 0L, SEEK_CUR); /* remise à zéro du tampon */
write_int(fp, n + 10);
Antoine
À vue de nez, l'implémentation de stdio de Microsoft ne respecte pas la
norme pour un fichier ouvert en "r+" ou "rb+" : si tu fais une lecture
suivie directement d'une écriture (sans remise-à-zéro de l'état d u
tampon), l'écriture n'est pas prise en compte au moment de fermer le
fichier, l'implémentation fait comme si le fichier était encore en mo de
lecture et ne met pas à jour le disque :-(
C'est ÀMHA non conforme : la norme précise bien que si tu fais le
contraire (écriture suivi de lecture), un programme pour être conform e
doit faire une remise-à-zéro intermédiaire : en creux, cela veut di re
que dans le sens que tu utilises, cela doit fonctionner.
En même temps, la solution est « simple » : il suffit de rajouter u ne
opération de remise-à-zéro même si c'est officiellement inutile: essaye
n = read_int(fp);
printf("n = %dn", n);
fseek(fp, 0L, SEEK_CUR); /* remise à zéro du tampon */
write_int(fp, n + 10);
Antoine
À vue de nez, l'implémentation de stdio de Microsoft ne respecte pas la
norme pour un fichier ouvert en "r+" ou "rb+" : si tu fais une lecture
suivie directement d'une écriture (sans remise-à-zéro de l'état d u
tampon), l'écriture n'est pas prise en compte au moment de fermer le
fichier, l'implémentation fait comme si le fichier était encore en mo de
lecture et ne met pas à jour le disque :-(
C'est ÀMHA non conforme : la norme précise bien que si tu fais le
contraire (écriture suivi de lecture), un programme pour être conform e
doit faire une remise-à-zéro intermédiaire : en creux, cela veut di re
que dans le sens que tu utilises, cela doit fonctionner.
En même temps, la solution est « simple » : il suffit de rajouter u ne
opération de remise-à-zéro même si c'est officiellement inutile: essaye
n = read_int(fp);
printf("n = %dn", n);
fseek(fp, 0L, SEEK_CUR); /* remise à zéro du tampon */
write_int(fp, n + 10);
Antoine
GurneyH écrivit :
>> Je suis peu habitué à manipuler des fichiers en lecture/écriture , et
>> je me trouve avec un code qui produit un résultat différent suivan t
>> qu'il est compilé et exécuté sous Ubuntu et GCC ou Windows et Mi ngW.
Ta première version écrivait en texte et relisait en binaire, clairem ent
c'est un mélange des genres... mais c'est corrigé.
Cela étant, les fichiers binaires ou textes n'ont rien à voir dans to n
problème : tu obtiens exactement le même résultat avec des fichiers texte.
>> Je commence par écrire 3 entiers dans un fichier.
>> J'ouvre une deuxième fois le fichier en mode rb+, je lis le premier
>> entier, et j'écris à la suite.
>> Problème, sous Ubuntu, cette écriture fonctionne bien, et l'affich age
>> du contenu du fichier me donne bien 1, 11, 3, qui est le résultat
>> attendu.
>> Sous Windows par contre, le fichier contient toujours 1, 2, 3.
Oui, j'obtiens la même chose, y compris avec SUA (le POSIX de Windows).
Ce qui me semble une non-conformité de la part de Microsoft.
>> Une explication?
À vue de nez, l'implémentation de stdio de Microsoft ne respecte pas la
norme pour un fichier ouvert en "r+" ou "rb+" : si tu fais une lecture
suivie directement d'une écriture (sans remise-à-zéro de l'état d u
tampon), l'écriture n'est pas prise en compte au moment de fermer le
fichier, l'implémentation fait comme si le fichier était encore en mo de
lecture et ne met pas à jour le disque :-(
C'est ÀMHA non conforme : la norme précise bien que si tu fais le
contraire (écriture suivi de lecture), un programme pour être conform e
doit faire une remise-à-zéro intermédiaire : en creux, cela veut di re
que dans le sens que tu utilises, cela doit fonctionner.
En même temps, la solution est « simple » : il suffit de rajouter u ne
opération de remise-à-zéro même si c'est officiellement inutile: essaye
n = read_int(fp);
printf("n = %dn", n);
fseek(fp, 0L, SEEK_CUR); /* remise à zéro du tampon */
write_int(fp, n + 10);
Antoine
GurneyH écrivit :
>> Je suis peu habitué à manipuler des fichiers en lecture/écriture , et
>> je me trouve avec un code qui produit un résultat différent suivan t
>> qu'il est compilé et exécuté sous Ubuntu et GCC ou Windows et Mi ngW.
Ta première version écrivait en texte et relisait en binaire, clairem ent
c'est un mélange des genres... mais c'est corrigé.
Cela étant, les fichiers binaires ou textes n'ont rien à voir dans to n
problème : tu obtiens exactement le même résultat avec des fichiers texte.
>> Je commence par écrire 3 entiers dans un fichier.
>> J'ouvre une deuxième fois le fichier en mode rb+, je lis le premier
>> entier, et j'écris à la suite.
>> Problème, sous Ubuntu, cette écriture fonctionne bien, et l'affich age
>> du contenu du fichier me donne bien 1, 11, 3, qui est le résultat
>> attendu.
>> Sous Windows par contre, le fichier contient toujours 1, 2, 3.
Oui, j'obtiens la même chose, y compris avec SUA (le POSIX de Windows).
Ce qui me semble une non-conformité de la part de Microsoft.
>> Une explication?
À vue de nez, l'implémentation de stdio de Microsoft ne respecte pas la
norme pour un fichier ouvert en "r+" ou "rb+" : si tu fais une lecture
suivie directement d'une écriture (sans remise-à-zéro de l'état d u
tampon), l'écriture n'est pas prise en compte au moment de fermer le
fichier, l'implémentation fait comme si le fichier était encore en mo de
lecture et ne met pas à jour le disque :-(
C'est ÀMHA non conforme : la norme précise bien que si tu fais le
contraire (écriture suivi de lecture), un programme pour être conform e
doit faire une remise-à-zéro intermédiaire : en creux, cela veut di re
que dans le sens que tu utilises, cela doit fonctionner.
En même temps, la solution est « simple » : il suffit de rajouter u ne
opération de remise-à-zéro même si c'est officiellement inutile: essaye
n = read_int(fp);
printf("n = %dn", n);
fseek(fp, 0L, SEEK_CUR); /* remise à zéro du tampon */
write_int(fp, n + 10);
Antoine
GurneyH écrivit :
>> Je suis peu habitué à manipuler des fichiers en lecture/écriture , et
>> je me trouve avec un code qui produit un résultat différent suivan t
>> qu'il est compilé et exécuté sous Ubuntu et GCC ou Windows et Mi ngW.
Ta première version écrivait en texte et relisait en binaire, clairem ent
c'est un mélange des genres... mais c'est corrigé.
Cela étant, les fichiers binaires ou textes n'ont rien à voir dans to n
problème : tu obtiens exactement le même résultat avec des fichiers texte.
>> Je commence par écrire 3 entiers dans un fichier.
>> J'ouvre une deuxième fois le fichier en mode rb+, je lis le premier
>> entier, et j'écris à la suite.
>> Problème, sous Ubuntu, cette écriture fonctionne bien, et l'affich age
>> du contenu du fichier me donne bien 1, 11, 3, qui est le résultat
>> attendu.
>> Sous Windows par contre, le fichier contient toujours 1, 2, 3.
Oui, j'obtiens la même chose, y compris avec SUA (le POSIX de Windows).
Ce qui me semble une non-conformité de la part de Microsoft.
>> Une explication?
À vue de nez, l'implémentation de stdio de Microsoft ne respecte pas la
norme pour un fichier ouvert en "r+" ou "rb+" : si tu fais une lecture
suivie directement d'une écriture (sans remise-à-zéro de l'état d u
tampon), l'écriture n'est pas prise en compte au moment de fermer le
fichier, l'implémentation fait comme si le fichier était encore en mo de
lecture et ne met pas à jour le disque :-(
C'est ÀMHA non conforme : la norme précise bien que si tu fais le
contraire (écriture suivi de lecture), un programme pour être conform e
doit faire une remise-à-zéro intermédiaire : en creux, cela veut di re
que dans le sens que tu utilises, cela doit fonctionner.
En même temps, la solution est « simple » : il suffit de rajouter u ne
opération de remise-à-zéro même si c'est officiellement inutile: essaye
n = read_int(fp);
printf("n = %dn", n);
fseek(fp, 0L, SEEK_CUR); /* remise à zéro du tampon */
write_int(fp, n + 10);
Antoine
On 29 nov, 15:00, Antoine Leca wrote:
> GurneyH écrivit :
> >> Je suis peu habitué à manipuler des fichiers en lecture/écritu re, et
> >> je me trouve avec un code qui produit un résultat différent suiv ant
> >> qu'il est compilé et exécuté sous Ubuntu et GCC ou Windows et MingW.
> Ta première version écrivait en texte et relisait en binaire, clair ement
> c'est un mélange des genres... mais c'est corrigé.
> Cela étant, les fichiers binaires ou textes n'ont rien à voir dans ton
> problème : tu obtiens exactement le même résultat avec des fichie rs texte.
> >> Je commence par écrire 3 entiers dans un fichier.
> >> J'ouvre une deuxième fois le fichier en mode rb+, je lis le premie r
> >> entier, et j'écris à la suite.
> >> Problème, sous Ubuntu, cette écriture fonctionne bien, et l'affi chage
> >> du contenu du fichier me donne bien 1, 11, 3, qui est le résultat
> >> attendu.
> >> Sous Windows par contre, le fichier contient toujours 1, 2, 3.
> Oui, j'obtiens la même chose, y compris avec SUA (le POSIX de Windows ).
> Ce qui me semble une non-conformité de la part de Microsoft.
> >> Une explication?
> À vue de nez, l'implémentation de stdio de Microsoft ne respecte pa s la
> norme pour un fichier ouvert en "r+" ou "rb+" : si tu fais une lecture
> suivie directement d'une écriture (sans remise-à-zéro de l'état du
> tampon), l'écriture n'est pas prise en compte au moment de fermer le
> fichier, l'implémentation fait comme si le fichier était encore en mode
> lecture et ne met pas à jour le disque :-(
> C'est ÀMHA non conforme : la norme précise bien que si tu fais le
> contraire (écriture suivi de lecture), un programme pour être confo rme
> doit faire une remise-à-zéro intermédiaire : en creux, cela veut dire
> que dans le sens que tu utilises, cela doit fonctionner.
> En même temps, la solution est « simple » : il suffit de rajouter une
> opération de remise-à-zéro même si c'est officiellement inutile : essaye
> n = read_int(fp);
> printf("n = %dn", n);
> fseek(fp, 0L, SEEK_CUR); /* remise à zéro du tampon */
> write_int(fp, n + 10);
> Antoine
Bonjour,
En consultant la norme C99, on peut lire
Norme C99 7.19.5.3
"When a file is opened with update mode ('+' as the second or third
character in the
above list of mode argument values), both input and output may be
performed on the
associated stream. However, output shall not be directly followed by
input without an
intervening call to the fflush function or to a file positioning
function (fseek,
fsetpos, or rewind), and input shall not be directly followed by
output without an
intervening call to a file positioning function, unless the input
operation encounters end-
of-file. Opening (or creating) a text file with update mode may
instead open (or create) a
binary stream in some implementations."
En particulier ce passage
"input shall not be directly followed by output without an intervening
call to a file positioning function". qui revient à la solution que
donnée Antoine Leca plus haut.
De la norme, je comprend:
Avec un fichier ouvert en mode "+"
lecture -> (rewind, fpos, fseek) -> écriture
éciture -> fflush -> lecture
Finalement, Il semble que le comportement sous Windows soit conforme.
Je termine par une question.
A votre connaissance, l'utilisation du mode "+" est, ou reste
anecdotique?
Merci
GurneyH
A votre connaissance, l'utilisation du mode "+" est, ou reste
anecdotique?
On 29 nov, 15:00, Antoine Leca <r...@localhost.invalid> wrote:
> GurneyH écrivit :
> >> Je suis peu habitué à manipuler des fichiers en lecture/écritu re, et
> >> je me trouve avec un code qui produit un résultat différent suiv ant
> >> qu'il est compilé et exécuté sous Ubuntu et GCC ou Windows et MingW.
> Ta première version écrivait en texte et relisait en binaire, clair ement
> c'est un mélange des genres... mais c'est corrigé.
> Cela étant, les fichiers binaires ou textes n'ont rien à voir dans ton
> problème : tu obtiens exactement le même résultat avec des fichie rs texte.
> >> Je commence par écrire 3 entiers dans un fichier.
> >> J'ouvre une deuxième fois le fichier en mode rb+, je lis le premie r
> >> entier, et j'écris à la suite.
> >> Problème, sous Ubuntu, cette écriture fonctionne bien, et l'affi chage
> >> du contenu du fichier me donne bien 1, 11, 3, qui est le résultat
> >> attendu.
> >> Sous Windows par contre, le fichier contient toujours 1, 2, 3.
> Oui, j'obtiens la même chose, y compris avec SUA (le POSIX de Windows ).
> Ce qui me semble une non-conformité de la part de Microsoft.
> >> Une explication?
> À vue de nez, l'implémentation de stdio de Microsoft ne respecte pa s la
> norme pour un fichier ouvert en "r+" ou "rb+" : si tu fais une lecture
> suivie directement d'une écriture (sans remise-à-zéro de l'état du
> tampon), l'écriture n'est pas prise en compte au moment de fermer le
> fichier, l'implémentation fait comme si le fichier était encore en mode
> lecture et ne met pas à jour le disque :-(
> C'est ÀMHA non conforme : la norme précise bien que si tu fais le
> contraire (écriture suivi de lecture), un programme pour être confo rme
> doit faire une remise-à-zéro intermédiaire : en creux, cela veut dire
> que dans le sens que tu utilises, cela doit fonctionner.
> En même temps, la solution est « simple » : il suffit de rajouter une
> opération de remise-à-zéro même si c'est officiellement inutile : essaye
> n = read_int(fp);
> printf("n = %dn", n);
> fseek(fp, 0L, SEEK_CUR); /* remise à zéro du tampon */
> write_int(fp, n + 10);
> Antoine
Bonjour,
En consultant la norme C99, on peut lire
Norme C99 7.19.5.3
"When a file is opened with update mode ('+' as the second or third
character in the
above list of mode argument values), both input and output may be
performed on the
associated stream. However, output shall not be directly followed by
input without an
intervening call to the fflush function or to a file positioning
function (fseek,
fsetpos, or rewind), and input shall not be directly followed by
output without an
intervening call to a file positioning function, unless the input
operation encounters end-
of-file. Opening (or creating) a text file with update mode may
instead open (or create) a
binary stream in some implementations."
En particulier ce passage
"input shall not be directly followed by output without an intervening
call to a file positioning function". qui revient à la solution que
donnée Antoine Leca plus haut.
De la norme, je comprend:
Avec un fichier ouvert en mode "+"
lecture -> (rewind, fpos, fseek) -> écriture
éciture -> fflush -> lecture
Finalement, Il semble que le comportement sous Windows soit conforme.
Je termine par une question.
A votre connaissance, l'utilisation du mode "+" est, ou reste
anecdotique?
Merci
GurneyH
A votre connaissance, l'utilisation du mode "+" est, ou reste
anecdotique?
On 29 nov, 15:00, Antoine Leca wrote:
> GurneyH écrivit :
> >> Je suis peu habitué à manipuler des fichiers en lecture/écritu re, et
> >> je me trouve avec un code qui produit un résultat différent suiv ant
> >> qu'il est compilé et exécuté sous Ubuntu et GCC ou Windows et MingW.
> Ta première version écrivait en texte et relisait en binaire, clair ement
> c'est un mélange des genres... mais c'est corrigé.
> Cela étant, les fichiers binaires ou textes n'ont rien à voir dans ton
> problème : tu obtiens exactement le même résultat avec des fichie rs texte.
> >> Je commence par écrire 3 entiers dans un fichier.
> >> J'ouvre une deuxième fois le fichier en mode rb+, je lis le premie r
> >> entier, et j'écris à la suite.
> >> Problème, sous Ubuntu, cette écriture fonctionne bien, et l'affi chage
> >> du contenu du fichier me donne bien 1, 11, 3, qui est le résultat
> >> attendu.
> >> Sous Windows par contre, le fichier contient toujours 1, 2, 3.
> Oui, j'obtiens la même chose, y compris avec SUA (le POSIX de Windows ).
> Ce qui me semble une non-conformité de la part de Microsoft.
> >> Une explication?
> À vue de nez, l'implémentation de stdio de Microsoft ne respecte pa s la
> norme pour un fichier ouvert en "r+" ou "rb+" : si tu fais une lecture
> suivie directement d'une écriture (sans remise-à-zéro de l'état du
> tampon), l'écriture n'est pas prise en compte au moment de fermer le
> fichier, l'implémentation fait comme si le fichier était encore en mode
> lecture et ne met pas à jour le disque :-(
> C'est ÀMHA non conforme : la norme précise bien que si tu fais le
> contraire (écriture suivi de lecture), un programme pour être confo rme
> doit faire une remise-à-zéro intermédiaire : en creux, cela veut dire
> que dans le sens que tu utilises, cela doit fonctionner.
> En même temps, la solution est « simple » : il suffit de rajouter une
> opération de remise-à-zéro même si c'est officiellement inutile : essaye
> n = read_int(fp);
> printf("n = %dn", n);
> fseek(fp, 0L, SEEK_CUR); /* remise à zéro du tampon */
> write_int(fp, n + 10);
> Antoine
Bonjour,
En consultant la norme C99, on peut lire
Norme C99 7.19.5.3
"When a file is opened with update mode ('+' as the second or third
character in the
above list of mode argument values), both input and output may be
performed on the
associated stream. However, output shall not be directly followed by
input without an
intervening call to the fflush function or to a file positioning
function (fseek,
fsetpos, or rewind), and input shall not be directly followed by
output without an
intervening call to a file positioning function, unless the input
operation encounters end-
of-file. Opening (or creating) a text file with update mode may
instead open (or create) a
binary stream in some implementations."
En particulier ce passage
"input shall not be directly followed by output without an intervening
call to a file positioning function". qui revient à la solution que
donnée Antoine Leca plus haut.
De la norme, je comprend:
Avec un fichier ouvert en mode "+"
lecture -> (rewind, fpos, fseek) -> écriture
éciture -> fflush -> lecture
Finalement, Il semble que le comportement sous Windows soit conforme.
Je termine par une question.
A votre connaissance, l'utilisation du mode "+" est, ou reste
anecdotique?
Merci
GurneyH
A votre connaissance, l'utilisation du mode "+" est, ou reste
anecdotique?
A votre connaissance, l'utilisation du mode "+" est fréquente, ou
reste anecdotique?
A votre connaissance, l'utilisation du mode "+" est fréquente, ou
reste anecdotique?
A votre connaissance, l'utilisation du mode "+" est fréquente, ou
reste anecdotique?
Norme C99 7.19.5.3
"When a file is opened with update mode ('+' as the second or
third character in the above list of mode argument values),
both input and output may be performed on the associated
stream. However, output shall not be directly followed by input
without an intervening call to the fflush function or to a file
positioning function (fseek, fsetpos, or rewind),
and input shall not be directly followed by output without an
intervening call to a file positioning function, unless the input
operation encounters end-of-file. [...]"
De la norme, je comprend:
Avec un fichier ouvert en mode "+"
lecture -> (rewind, fpos, fseek) -> écriture
éciture -> fflush -> lecture
A votre connaissance, l'utilisation du mode "+" est fréquente,
ou reste anecdotique?
Norme C99 7.19.5.3
"When a file is opened with update mode ('+' as the second or
third character in the above list of mode argument values),
both input and output may be performed on the associated
stream. However, output shall not be directly followed by input
without an intervening call to the fflush function or to a file
positioning function (fseek, fsetpos, or rewind),
and input shall not be directly followed by output without an
intervening call to a file positioning function, unless the input
operation encounters end-of-file. [...]"
De la norme, je comprend:
Avec un fichier ouvert en mode "+"
lecture -> (rewind, fpos, fseek) -> écriture
éciture -> fflush -> lecture
A votre connaissance, l'utilisation du mode "+" est fréquente,
ou reste anecdotique?
Norme C99 7.19.5.3
"When a file is opened with update mode ('+' as the second or
third character in the above list of mode argument values),
both input and output may be performed on the associated
stream. However, output shall not be directly followed by input
without an intervening call to the fflush function or to a file
positioning function (fseek, fsetpos, or rewind),
and input shall not be directly followed by output without an
intervening call to a file positioning function, unless the input
operation encounters end-of-file. [...]"
De la norme, je comprend:
Avec un fichier ouvert en mode "+"
lecture -> (rewind, fpos, fseek) -> écriture
éciture -> fflush -> lecture
A votre connaissance, l'utilisation du mode "+" est fréquente,
ou reste anecdotique?