Avec p2 qui pointe sur une chaine saisie avec fgets (ex."abcd")
dans for ( p2 ; *p2 ; p2++ )
Pourquoi l'incr=E9mentation se fait sur 6 intervalles en m=E9moire.
0 =3D a
1 =3D b
2 =3D c
3 =3D d
4 =3D \0
5 =3D ???
A quoi correspond la derni=E8re position (numero 5) ?
(En fait, je veux dire que je dois d=E9cr=E9menter 2 fois apres la fin
de la boucle for pour pointer p2 sur 'd' en position 3). Ca veut dire
qu'en plus de '\0', fgets inclue un autre caract=E8re.
Question suppl=E9mentaire (culture g=E9n=E9ral en informatique) :
La chaine enregistr=E9e avec fgets se trouve dans la memoire ram ou
dans un des registres?
<...>But the knowledge that this internal code has numerous external representations depending upon operating system and medium is equally widespread.
Ben y'a encore du boulot ... Chez certains, ça a du mal çà rentrer...
Antoine Leca
-ed- écrivit :
On 24 nov, 17:19, Antoine Leca wrote:
while (*s == 'n' || *s == 'r') { *s-- = ' '; }
Oui ; même si c'est inutile au vu de la norme, c'est en effet une manière solide de faire.
Si le flux est ouvert en mode texte, le test de 'r' est inutile à moins qu'il s'agisse d'être compatible
Exactement.
evec des implémentations non conformes... Si c'est le cas, on se s'en sort plus...
Il ne s'agit pas d'implémentation non conformes.
Une implémentation conforme est capable de traduire tous les programmes strictement conformes ; mais ce n'est pas exclusif (heureusement, car peu de programmes sont strictement conformes) : une telle implémentation peut AUSSI traduire des programmes non strictement conformes (la norme les appelle programmes conformes, mais je vais laisser tomber ce terme qui ne fait que rajouter à la confusion). Et pour ce faire, les implémenteurs programment des comportements, et les utilisateurs jouent avec des options, qui peuvent parfois avoir des effets surprenants ; il convient ÀMHA de se prémunir dans la mesure du possible des conséquences négatives. Une telle option dans le monde MSDOS est celle qui permet de définir ce qu'est une fin de ligne, savoir si c'est CR+LF (normal) ou LF (compatible avec d'autres environnements, par exemple pour écrire des filtres); et avec la seconde option, tu te retrouves avec des 12 dans les flux texte...
Antoine
-ed- écrivit :
On 24 nov, 17:19, Antoine Leca <r...@localhost.invalid> wrote:
while (*s == 'n' || *s == 'r') {
*s-- = ' ';
}
Oui ; même si c'est inutile au vu de la norme, c'est en effet une
manière solide de faire.
Si le flux est ouvert en mode texte, le test de 'r' est inutile à
moins qu'il s'agisse d'être compatible
Exactement.
evec des implémentations non conformes...
Si c'est le cas, on se s'en sort plus...
Il ne s'agit pas d'implémentation non conformes.
Une implémentation conforme est capable de traduire tous les programmes
strictement conformes ; mais ce n'est pas exclusif (heureusement, car
peu de programmes sont strictement conformes) : une telle implémentation
peut AUSSI traduire des programmes non strictement conformes (la norme
les appelle programmes conformes, mais je vais laisser tomber ce terme
qui ne fait que rajouter à la confusion).
Et pour ce faire, les implémenteurs programment des comportements, et
les utilisateurs jouent avec des options, qui peuvent parfois avoir des
effets surprenants ; il convient ÀMHA de se prémunir dans la mesure du
possible des conséquences négatives.
Une telle option dans le monde MSDOS est celle qui permet de définir ce
qu'est une fin de ligne, savoir si c'est CR+LF (normal) ou LF
(compatible avec d'autres environnements, par exemple pour écrire des
filtres); et avec la seconde option, tu te retrouves avec des 12 dans
les flux texte...
Oui ; même si c'est inutile au vu de la norme, c'est en effet une manière solide de faire.
Si le flux est ouvert en mode texte, le test de 'r' est inutile à moins qu'il s'agisse d'être compatible
Exactement.
evec des implémentations non conformes... Si c'est le cas, on se s'en sort plus...
Il ne s'agit pas d'implémentation non conformes.
Une implémentation conforme est capable de traduire tous les programmes strictement conformes ; mais ce n'est pas exclusif (heureusement, car peu de programmes sont strictement conformes) : une telle implémentation peut AUSSI traduire des programmes non strictement conformes (la norme les appelle programmes conformes, mais je vais laisser tomber ce terme qui ne fait que rajouter à la confusion). Et pour ce faire, les implémenteurs programment des comportements, et les utilisateurs jouent avec des options, qui peuvent parfois avoir des effets surprenants ; il convient ÀMHA de se prémunir dans la mesure du possible des conséquences négatives. Une telle option dans le monde MSDOS est celle qui permet de définir ce qu'est une fin de ligne, savoir si c'est CR+LF (normal) ou LF (compatible avec d'autres environnements, par exemple pour écrire des filtres); et avec la seconde option, tu te retrouves avec des 12 dans les flux texte...
Antoine
Antoine Leca
a écrit :
On 24 nov, 17:10, Antoine Leca wrote:
Pascal écrivit :
Est-ce que fgets a un comportement différent selon l'OS (Djgpp Microsoft xp ou Linux Gcc) ?
Non.
Parce que sous Windows le pointeur se trouve 1 position supplémentaire après la fin de la chaîne saisie
Huh ? Peux-tu préciser le compilateur utilisé et les options de compilations, s'il te plaît.
Sous Windows : djgpp Linux : gcc pas d'option de compilation que je sache (niveau débutant) : gcc fichier.c -o fichier.exe ou gcc fichier.c -o fichier
Je n'ai pas fait le test avec Linux. Mais je suis aller réinstaller mon vieux DJGPP de derrière les fagots (d'après les dates de fichiers, cela faisait plus de quatre ans que cela ne m'était pas arrivé ; d'ailleurs, ce serait bien que tu te mettes à jour, DJGPP n'est pas un compilateur pour Windows mais pour MS-DOS, un produit certes très utile mais dont le développement cessa en 1993) ; et donc avec la version 2.04, sans utiliser d'options de compilation spécifiques, j'ai le même comportement avec DJGPP qu'avec les autres : la fin de ligne est constituée d'un seul caractère, n.
Voir ci-après un programme de test compilable ; je n'ai pas réussi à lui faire montrer des CR, même avec des acrobaties du genre ECHO toto | prgm prgm <turlututu TYPE fichier | prgm Je n'ai pas corrigé le débordement par le début (underflow), attention avec les lignes vides...
int putcx(int c) { switch(c) { case 'a': printf("a"); break; case 'b': printf("b"); break; case 't': printf("t"); break; case 'n': printf("n"); break; case 'v': printf("v"); break; case 'f': printf("f"); break; case 'r': printf("r"); break; case ''': printf("'"); break; case '"': printf(""");break; case '': printf("\");break; /* les trigraphes et par conséquent ? sont laissés * comme exercice au lecteur attentif... */ default: if( isprint(c) ) putchar(c); else printf("%03o",(unsigned char)c); break; } return c; }
#include <stdio.h>
int main(void) { char Ch[101] ; char *p1, *p2 ; int Pali ;
p2 = Ch ;
printf("nEntrez une ligne de texte (max.100 caract.) : n") ; assert(NULL! fgets(Ch, 101, stdin) ); printf("fgets donne <%.50s>, len=%u, soit "",Ch,(unsigned)strlen(Ch)); for(p1=Ch;*p1;)putcx(*p1++); putcx(*p1);
for ( p2 ; *p2 ; p2++ ) ; printf(""np2 avance de %d, p2-2 pointe sur ", p2-Ch); putcx(p2[-2]); printf(", p2-1=>"); putcx(p2[-1]); printf(", p2=>"); putcx(*p2);
p2 = p2-2 ;
printf("np2 = p2-2, p2 pointe maintenant sur "); putcx(*p2); printf(", p2+1 pointe sur "); putcx(p2[1]);putchar('n'); return 0;}
bpascal123@googlemail.com a écrit :
On 24 nov, 17:10, Antoine Leca <r...@localhost.invalid> wrote:
Pascal écrivit :
Est-ce que fgets a un comportement différent selon l'OS (Djgpp
Microsoft xp ou Linux Gcc) ?
Non.
Parce que sous Windows le pointeur se
trouve 1 position supplémentaire après la fin de la chaîne saisie
Huh ? Peux-tu préciser le compilateur utilisé et les options de
compilations, s'il te plaît.
Sous Windows : djgpp
Linux : gcc
pas d'option de compilation que je sache (niveau débutant) : gcc
fichier.c -o fichier.exe ou gcc fichier.c -o fichier
Je n'ai pas fait le test avec Linux.
Mais je suis aller réinstaller mon vieux DJGPP de derrière les fagots
(d'après les dates de fichiers, cela faisait plus de quatre ans que cela
ne m'était pas arrivé ; d'ailleurs, ce serait bien que tu te mettes à
jour, DJGPP n'est pas un compilateur pour Windows mais pour MS-DOS, un
produit certes très utile mais dont le développement cessa en 1993) ;
et donc avec la version 2.04, sans utiliser d'options de compilation
spécifiques, j'ai le même comportement avec DJGPP qu'avec les autres :
la fin de ligne est constituée d'un seul caractère, n.
Voir ci-après un programme de test compilable ; je n'ai pas réussi à lui
faire montrer des CR, même avec des acrobaties du genre
ECHO toto | prgm
prgm <turlututu
TYPE fichier | prgm
Je n'ai pas corrigé le débordement par le début (underflow), attention
avec les lignes vides...
int putcx(int c)
{
switch(c) {
case 'a': printf("\a"); break;
case 'b': printf("\b"); break;
case 't': printf("\t"); break;
case 'n': printf("\n"); break;
case 'v': printf("\v"); break;
case 'f': printf("\f"); break;
case 'r': printf("\r"); break;
case ''': printf("\'"); break;
case '"': printf("\"");break;
case '\': printf("\\");break;
/* les trigraphes et par conséquent ? sont laissés
* comme exercice au lecteur attentif... */
default:
if( isprint(c) )
putchar(c);
else
printf("\%03o",(unsigned char)c);
break;
}
return c;
}
#include <stdio.h>
int main(void)
{
char Ch[101] ;
char *p1, *p2 ;
int Pali ;
p2 = Ch ;
printf("nEntrez une ligne de texte (max.100 caract.) : n") ;
assert(NULL! fgets(Ch, 101, stdin)
);
printf("fgets donne <%.50s>, len=%u, soit "",Ch,(unsigned)strlen(Ch));
for(p1=Ch;*p1;)putcx(*p1++); putcx(*p1);
for ( p2 ; *p2 ; p2++ )
;
printf(""np2 avance de %d, p2-2 pointe sur ", p2-Ch); putcx(p2[-2]);
printf(", p2-1=>"); putcx(p2[-1]);
printf(", p2=>"); putcx(*p2);
p2 = p2-2 ;
printf("np2 = p2-2, p2 pointe maintenant sur "); putcx(*p2);
printf(", p2+1 pointe sur "); putcx(p2[1]);putchar('n');
return 0;}
Est-ce que fgets a un comportement différent selon l'OS (Djgpp Microsoft xp ou Linux Gcc) ?
Non.
Parce que sous Windows le pointeur se trouve 1 position supplémentaire après la fin de la chaîne saisie
Huh ? Peux-tu préciser le compilateur utilisé et les options de compilations, s'il te plaît.
Sous Windows : djgpp Linux : gcc pas d'option de compilation que je sache (niveau débutant) : gcc fichier.c -o fichier.exe ou gcc fichier.c -o fichier
Je n'ai pas fait le test avec Linux. Mais je suis aller réinstaller mon vieux DJGPP de derrière les fagots (d'après les dates de fichiers, cela faisait plus de quatre ans que cela ne m'était pas arrivé ; d'ailleurs, ce serait bien que tu te mettes à jour, DJGPP n'est pas un compilateur pour Windows mais pour MS-DOS, un produit certes très utile mais dont le développement cessa en 1993) ; et donc avec la version 2.04, sans utiliser d'options de compilation spécifiques, j'ai le même comportement avec DJGPP qu'avec les autres : la fin de ligne est constituée d'un seul caractère, n.
Voir ci-après un programme de test compilable ; je n'ai pas réussi à lui faire montrer des CR, même avec des acrobaties du genre ECHO toto | prgm prgm <turlututu TYPE fichier | prgm Je n'ai pas corrigé le débordement par le début (underflow), attention avec les lignes vides...
int putcx(int c) { switch(c) { case 'a': printf("a"); break; case 'b': printf("b"); break; case 't': printf("t"); break; case 'n': printf("n"); break; case 'v': printf("v"); break; case 'f': printf("f"); break; case 'r': printf("r"); break; case ''': printf("'"); break; case '"': printf(""");break; case '': printf("\");break; /* les trigraphes et par conséquent ? sont laissés * comme exercice au lecteur attentif... */ default: if( isprint(c) ) putchar(c); else printf("%03o",(unsigned char)c); break; } return c; }
#include <stdio.h>
int main(void) { char Ch[101] ; char *p1, *p2 ; int Pali ;
p2 = Ch ;
printf("nEntrez une ligne de texte (max.100 caract.) : n") ; assert(NULL! fgets(Ch, 101, stdin) ); printf("fgets donne <%.50s>, len=%u, soit "",Ch,(unsigned)strlen(Ch)); for(p1=Ch;*p1;)putcx(*p1++); putcx(*p1);
for ( p2 ; *p2 ; p2++ ) ; printf(""np2 avance de %d, p2-2 pointe sur ", p2-Ch); putcx(p2[-2]); printf(", p2-1=>"); putcx(p2[-1]); printf(", p2=>"); putcx(*p2);
p2 = p2-2 ;
printf("np2 = p2-2, p2 pointe maintenant sur "); putcx(*p2); printf(", p2+1 pointe sur "); putcx(p2[1]);putchar('n'); return 0;}
bpascal123
Merci tout le monde. Je vais d'exercice en exercice et j'oublie de suivre certaines discutions. Ca serait bien si on pouvait tout télécharger d'un trait en pdf... Mais je pense que je peux retrouver ce post dans quelques mois voire un an ou 2... Merci, bonnes fêtes de fin d'année!
Merci tout le monde. Je vais d'exercice en exercice et j'oublie de
suivre certaines discutions. Ca serait bien si on pouvait tout
télécharger d'un trait en pdf... Mais je pense que je peux retrouver
ce post dans quelques mois voire un an ou 2...
Merci, bonnes fêtes de fin d'année!
Merci tout le monde. Je vais d'exercice en exercice et j'oublie de suivre certaines discutions. Ca serait bien si on pouvait tout télécharger d'un trait en pdf... Mais je pense que je peux retrouver ce post dans quelques mois voire un an ou 2... Merci, bonnes fêtes de fin d'année!
