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?
In article <4b0bf8c0$0$969$, Richard Delorme wrote:
Le 24/11/2009 15:47, Marc Espie a écrit :
C'est normal, sous certains OS, dont ceux de Microsoft, la fin de ligne contient deux caractères ("nr" ou le contraire) au lien d'un seul ("n") sous Unix.
Euh non, ce que tu decris, c'est une implementation "non conforme" ou du moins qui a decide de ne pas implementer la distinction flux binaire/flux texte.
Tous les Unix sont donc non conformes ?
... et sur lesquels les formats de fichiers concernes sont effectivement differents, ce qui est le cas sur windows.
In article <4b0bf8c0$0$969$ba4acef3@news.orange.fr>,
Richard Delorme <abulmo@nospam.fr> wrote:
Le 24/11/2009 15:47, Marc Espie a écrit :
C'est normal, sous certains OS, dont ceux de Microsoft, la fin de ligne
contient deux caractères ("nr" ou le contraire) au lien d'un seul
("n") sous Unix.
Euh non, ce que tu decris, c'est une implementation "non conforme" ou du
moins qui a decide de ne pas implementer la distinction flux binaire/flux
texte.
Tous les Unix sont donc non conformes ?
... et sur lesquels les formats de fichiers concernes sont effectivement
differents, ce qui est le cas sur windows.
In article <4b0bf8c0$0$969$, Richard Delorme wrote:
Le 24/11/2009 15:47, Marc Espie a écrit :
C'est normal, sous certains OS, dont ceux de Microsoft, la fin de ligne contient deux caractères ("nr" ou le contraire) au lien d'un seul ("n") sous Unix.
Euh non, ce que tu decris, c'est une implementation "non conforme" ou du moins qui a decide de ne pas implementer la distinction flux binaire/flux texte.
Tous les Unix sont donc non conformes ?
... et sur lesquels les formats de fichiers concernes sont effectivement differents, ce qui est le cas sur windows.
espie
In article , Jean-Marc Bourguet wrote:
(Marc Espie) writes:
De facon encore plus drole, d'apres 7.19.2.2, il y a tres peu d'implementations standard dans la nature... c'est frequent d'avoir des espaces avant le 'n', par exemple).
Quel probleme y a-t'il?
Whether space characters that are written out immediately before a new-line character appear when read in is implementation-defined.
Tu as raison, j'ai lu un peut vite, j'etais sur le paragraphe du dessus, qui expliquait dans quelle mesure on relit ce qui a ete ecrit...
In article <pxb7htgaq1r.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> wrote:
espie@lain.home (Marc Espie) writes:
De facon encore plus drole, d'apres 7.19.2.2, il y a tres peu
d'implementations standard dans la nature... c'est frequent d'avoir des
espaces avant le 'n', par exemple).
Quel probleme y a-t'il?
Whether space characters that are written out immediately before a
new-line character
appear when read in is implementation-defined.
Tu as raison, j'ai lu un peut vite, j'etais sur le paragraphe du dessus,
qui expliquait dans quelle mesure on relit ce qui a ete ecrit...
De facon encore plus drole, d'apres 7.19.2.2, il y a tres peu d'implementations standard dans la nature... c'est frequent d'avoir des espaces avant le 'n', par exemple).
Quel probleme y a-t'il?
Whether space characters that are written out immediately before a new-line character appear when read in is implementation-defined.
Tu as raison, j'ai lu un peut vite, j'etais sur le paragraphe du dessus, qui expliquait dans quelle mesure on relit ce qui a ete ecrit...
espie
In article <heh122$fkl$, 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.
C'est surtout une maniere fausse, ca s'appelle un buffer underflow....
In article <heh122$fkl$1@shakotay.alphanet.ch>,
Antoine Leca <root@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.
C'est surtout une maniere fausse, ca s'appelle un buffer underflow....
Oui ; même si c'est inutile au vu de la norme, c'est en effet une manière solide de faire.
C'est surtout une maniere fausse, ca s'appelle un buffer underflow....
Tu as raison, j'ai lu un peu trop vite, j'étais sur l'idée du paragraphe du dessus, qui traitait des caractères CR et LF...
Antoine
-ed-
On 24 nov, 12:49, Richard Delorme wrote:
C'est normal, sous certains OS, dont ceux de Microsoft, la fin de ligne contient deux caractères ("nr" ou le contraire) au lien d'un seul ("n") sous Unix. Quelque soit l'OS, si s est un pointeur vers le dernier caractère non nul de la chaine, il suffit de vérifier son contenu pour effacer les caractères de fin de ligne :
while (*s == 'n' || *s == 'r') { *s-- = ' ';
}
Non. Vu du c, et dans un flux ouvert en mode texte, une fin de ligne est toujours 'n', quelque soit ce que fait l'OS (n, r ou rn).
On 24 nov, 12:49, Richard Delorme <abu...@nospam.fr> wrote:
C'est normal, sous certains OS, dont ceux de Microsoft, la fin de ligne
contient deux caractères ("nr" ou le contraire) au lien d'un seul
("n") sous Unix.
Quelque soit l'OS, si s est un pointeur vers le dernier caractère non
nul de la chaine, il suffit de vérifier son contenu pour effacer les
caractères de fin de ligne :
while (*s == 'n' || *s == 'r') {
*s-- = ' ';
}
Non. Vu du c, et dans un flux ouvert en mode texte, une fin de ligne
est toujours 'n', quelque soit ce que fait l'OS (n, r ou rn).
C'est normal, sous certains OS, dont ceux de Microsoft, la fin de ligne contient deux caractères ("nr" ou le contraire) au lien d'un seul ("n") sous Unix. Quelque soit l'OS, si s est un pointeur vers le dernier caractère non nul de la chaine, il suffit de vérifier son contenu pour effacer les caractères de fin de ligne :
while (*s == 'n' || *s == 'r') { *s-- = ' ';
}
Non. Vu du c, et dans un flux ouvert en mode texte, une fin de ligne est toujours 'n', quelque soit ce que fait l'OS (n, r ou rn).
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 evec des implémentations non conformes... Si c'est le cas, on se s'en sort plus... .
On 24 nov, 17:19, Antoine Leca <r...@localhost.invalid> wrote:
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 evec des implémentations non
conformes... Si c'est le cas, on se s'en sort plus...
.
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 evec des implémentations non conformes... Si c'est le cas, on se s'en sort plus... .
bpascal123
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.
Antoine
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
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.
Antoine
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
> 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.
Antoine
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
candide
-ed- a écrit :
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 evec des implémentations non conformes... Si c'est le cas, on se s'en sort plus... .
Non conformes ? ce n'est pas la question. La Norme dit :
5.2.2 Character display semantics (...) Each of these escape sequences shall produce a unique implementation-defined value which can be stored in a single char object. The external representations in a text file need not be identical to the internal representations, and are outside the scope of this International Standard.
et le Rationale de confirmer :
Although ISO/IEC 646 deprecates the combination of the motion to the next line with a motion to the initial position on the line, the C Standard uses new-line to designate the end-of-line internal code represented by the escape sequence 'n'. While this ambiguity is perhaps unfortunate, use of the term in the latter sense is nearly universal within the C community. But the knowledge that this internal code has numerous external representations depending upon operating system and medium is equally widespread.
-ed- a écrit :
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 evec des implémentations non
conformes... Si c'est le cas, on se s'en sort plus...
.
Non conformes ? ce n'est pas la question. La Norme dit :
5.2.2 Character display semantics
(...)
Each of these escape sequences shall produce a unique
implementation-defined value which can be stored in a single char object.
The external representations in a text file need not be identical to the
internal representations, and are outside the scope of this
International Standard.
et le Rationale de confirmer :
Although ISO/IEC 646 deprecates the combination of the motion to the
next line with a motion to the initial position on the line, the C
Standard uses new-line to designate the end-of-line internal code
represented by the escape sequence 'n'. While this ambiguity is perhaps
unfortunate, use of the term in the latter sense is nearly universal
within the C community. But the knowledge that this internal code has
numerous external representations depending upon operating system and
medium is equally widespread.
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 evec des implémentations non conformes... Si c'est le cas, on se s'en sort plus... .
Non conformes ? ce n'est pas la question. La Norme dit :
5.2.2 Character display semantics (...) Each of these escape sequences shall produce a unique implementation-defined value which can be stored in a single char object. The external representations in a text file need not be identical to the internal representations, and are outside the scope of this International Standard.
et le Rationale de confirmer :
Although ISO/IEC 646 deprecates the combination of the motion to the next line with a motion to the initial position on the line, the C Standard uses new-line to designate the end-of-line internal code represented by the escape sequence 'n'. While this ambiguity is perhaps unfortunate, use of the term in the latter sense is nearly universal within the C community. But the knowledge that this internal code has numerous external representations depending upon operating system and medium is equally widespread.
candide
a écrit :
pas d'option de compilation que je sache (niveau débutant) : gcc fichier.c -o fichier.exe ou gcc fichier.c -o fichier
Quel que soit le niveau, il est impensable de ne pas compiler avec options allumées (minimum -Wall -Wextra), c'est vraiment le B-A-BA. Tout cours (oral ou écrit) qui n'insiste pas sur cela doit faire l'objet des plus vives suspicions.
bpascal123@googlemail.com a écrit :
pas d'option de compilation que je sache (niveau débutant) : gcc
fichier.c -o fichier.exe ou gcc fichier.c -o fichier
Quel que soit le niveau, il est impensable de ne pas compiler avec
options allumées (minimum -Wall -Wextra), c'est vraiment le B-A-BA. Tout
cours (oral ou écrit) qui n'insiste pas sur cela doit faire l'objet des
plus vives suspicions.
pas d'option de compilation que je sache (niveau débutant) : gcc fichier.c -o fichier.exe ou gcc fichier.c -o fichier
Quel que soit le niveau, il est impensable de ne pas compiler avec options allumées (minimum -Wall -Wextra), c'est vraiment le B-A-BA. Tout cours (oral ou écrit) qui n'insiste pas sur cela doit faire l'objet des plus vives suspicions.
> 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.
Non conformes ? ce n'est pas la question. La Norme dit :
5.2.2 Character display semantics (...) Each of these escape sequences shall produce a unique implementation-deï¬ned value which can be stored in a single char object. The external representations in a text ï¬le need not be identical to the internal representations, and are outside the scope of this International Standard.
et le Rationale de confirmer :
Although ISO/IEC 646 deprecates the combination of the motion to the next line with a motion to the initial position on the line, the C Standard uses new-line to designate the end-of-line internal code represented by the escape sequence 'n'. While this ambiguity is perhaps unfortunate, use of the term in the latter sense is nearly universal within the C community. But the knowledge that this internal code has numerous external representations depending upon operating system and medium is equally widespread.
> 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.
Non conformes ? ce n'est pas la question. La Norme dit :
5.2.2 Character display semantics
(...)
Each of these escape sequences shall produce a unique
implementation-deï¬ned value which can be stored in a single char object.
The external representations in a text ï¬le need not be identical to the
internal representations, and are outside the scope of this
International Standard.
et le Rationale de confirmer :
Although ISO/IEC 646 deprecates the combination of the motion to the
next line with a motion to the initial position on the line, the C
Standard uses new-line to designate the end-of-line internal code
represented by the escape sequence 'n'. While this ambiguity is perhaps
unfortunate, use of the term in the latter sense is nearly universal
within the C community. But the knowledge that this internal code has
numerous external representations depending upon operating system and
medium is equally widespread.
> 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.
Non conformes ? ce n'est pas la question. La Norme dit :
5.2.2 Character display semantics (...) Each of these escape sequences shall produce a unique implementation-deï¬ned value which can be stored in a single char object. The external representations in a text ï¬le need not be identical to the internal representations, and are outside the scope of this International Standard.
et le Rationale de confirmer :
Although ISO/IEC 646 deprecates the combination of the motion to the next line with a motion to the initial position on the line, the C Standard uses new-line to designate the end-of-line internal code represented by the escape sequence 'n'. While this ambiguity is perhaps unfortunate, use of the term in the latter sense is nearly universal within the C community. But the knowledge that this internal code has numerous external representations depending upon operating system and medium is equally widespread.
