je suis en train de faire un petit programme client et serveur qui echange
des messages. Dans cetains messages il y a deux valeur separer par des deux
points.
ex:
valeurun:valeurdeux
j'aimerais savoir si sscanf permet de gerer le separateur : ou faut il
utiliser une autre fonction? j'ai utilise sscanf("%s:%s", var1, var2); mais
ca ne marche pas.
PS: pour les courageux qui lisent mes posts jusqu'au bout, voici un petit test d'acuité visuelle : Pour quelles raisons ED ne doit-il pas utiliser le code suivant pour sa conversion de dates :
Parce qu'il sait que sizeof("??/??/????") == 6 et il utilisera plutot sizeof("00/00/0000")
"??/??/????" -> ????
Sans doute une histoire de trigrammes, mais je ne les connais pas du tout .... Est-ce que ca veut dire que ??/??/ -> ?
(Au début j'avais pensé que ça valait sizeof(char *) : je me fais avoir à chaque fois, alors j'ai fait le test...)
PS: pour les courageux qui lisent mes posts jusqu'au bout, voici un petit test
d'acuité visuelle :
Pour quelles raisons ED ne doit-il pas utiliser le code suivant pour sa
conversion de dates :
PS: pour les courageux qui lisent mes posts jusqu'au bout, voici un petit test d'acuité visuelle : Pour quelles raisons ED ne doit-il pas utiliser le code suivant pour sa conversion de dates :
Parce qu'il sait que sizeof("??/??/????") == 6 et il utilisera plutot sizeof("00/00/0000")
"??/??/????" -> ????
Sans doute une histoire de trigrammes, mais je ne les connais pas du tout ....
Est-ce que ca veut dire que ??/??/ -> ?
(Au début j'avais pensé que ça valait sizeof(char *) : je me fais avoir à chaque
fois, alors j'ai fait le test...)
Bravo, je crois (suis sûr) que tu as gagné ;-), j'ai relu la norme, et c'est bien toutes les séquences de trigraphes qui sont remplacées, j'ai eu un soupcon dessus mais je me suis dit que ca ne pouvait pas arriver dans les chaines. ??/??/???? => ???? => ???? + le ' ' => le sizeof vaut bien 6.
Encore bravo, c'était bien sioux.
Regis
Yves ROMAN wrote:
PS: pour les courageux qui lisent mes posts jusqu'au bout, voici un
petit test
d'acuité visuelle :
Pour quelles raisons ED ne doit-il pas utiliser le code suivant
pour sa
Parce qu'il sait que sizeof("??/??/????") == 6
et il utilisera plutot sizeof("00/00/0000")
"??/??/????" -> ????
Sans doute une histoire de trigrammes, mais je ne les connais pas du
tout ....
Est-ce que ca veut dire que ??/??/ -> ?
(Au début j'avais pensé que ça valait sizeof(char *) : je me fais
avoir à chaque
fois, alors j'ai fait le test...)
Bravo, je crois (suis sûr) que tu as gagné ;-), j'ai relu la norme,
et c'est bien toutes les séquences de trigraphes qui sont remplacées,
j'ai eu un soupcon dessus mais je me suis dit que ca ne pouvait pas
arriver dans les chaines. ??/??/???? => \???? => ???? + le ' ' => le
sizeof vaut bien 6.
Parce qu'il sait que sizeof("??/??/????") == 6 et il utilisera plutot sizeof("00/00/0000")
"??/??/????" -> ????
Sans doute une histoire de trigrammes, mais je ne les connais pas du tout ....
Est-ce que ca veut dire que ??/??/ -> ?
(Au début j'avais pensé que ça valait sizeof(char *) : je me fais avoir à chaque
fois, alors j'ai fait le test...)
Bravo, je crois (suis sûr) que tu as gagné ;-), j'ai relu la norme, et c'est bien toutes les séquences de trigraphes qui sont remplacées, j'ai eu un soupcon dessus mais je me suis dit que ca ne pouvait pas arriver dans les chaines. ??/??/???? => ???? => ???? + le ' ' => le sizeof vaut bien 6.
Encore bravo, c'était bien sioux.
Regis
AG
Yves ROMAN wrote:
Parce qu'il sait que sizeof("??/??/????") == 6
??? chez moi sizeof("??/??/????")=
(il faut compter le finale ajouté aux chaines de caractère constantes).
Y a un truc que j'ai loupé là ?
Yves ROMAN wrote:
Parce qu'il sait que sizeof("??/??/????") == 6
??? chez moi sizeof("??/??/????")=
(il faut compter le finale ajouté aux chaines de caractère constantes).
(il faut compter le finale ajouté aux chaines de caractère constantes).
Y a un truc que j'ai loupé là ?
Targeur fou
AG wrote:
Yves ROMAN wrote:
Parce qu'il sait que sizeof("??/??/????") == 6
??? chez moi sizeof("??/??/????")=
(il faut compter le finale ajouté aux chaines de caractère constantes).
Y a un truc que j'ai loupé là ?
Peut-être au niveau du compilo, si tu utilises gcc, je crois qu'il les ignore par défaut. Si tu utilises l'option -Wall combinée avec les classiques -stdMachin -pedantic, il prendra en compte les trigraphes mais devrait aussi et surtout te prévenir du malin.
Regis
AG wrote:
Yves ROMAN wrote:
Parce qu'il sait que sizeof("??/??/????") == 6
??? chez moi sizeof("??/??/????")==11
(il faut compter le finale ajouté aux chaines de caractère
constantes).
Y a un truc que j'ai loupé là ?
Peut-être au niveau du compilo, si tu utilises gcc, je crois qu'il les
ignore par défaut. Si tu utilises l'option -Wall combinée avec les
classiques -stdMachin -pedantic, il prendra en compte les trigraphes
mais devrait aussi et surtout te prévenir du malin.
(il faut compter le finale ajouté aux chaines de caractère constantes).
Y a un truc que j'ai loupé là ?
Peut-être au niveau du compilo, si tu utilises gcc, je crois qu'il les ignore par défaut. Si tu utilises l'option -Wall combinée avec les classiques -stdMachin -pedantic, il prendra en compte les trigraphes mais devrait aussi et surtout te prévenir du malin.
Regis
AG
AG wrote:
Y a un truc que j'ai loupé là ? ben l'option -trigraphs en compilant alors...
AG wrote:
Y a un truc que j'ai loupé là ?
ben l'option -trigraphs en compilant alors...
Y a un truc que j'ai loupé là ? ben l'option -trigraphs en compilant alors...
Yves ROMAN
Yves ROMAN wrote:
Parce qu'il sait que sizeof("??/??/????") == 6 et il utilisera plutot sizeof("00/00/0000")
"??/??/????" -> ????
Sans doute une histoire de trigrammes, mais je ne les connais pas du tout ....
Est-ce que ca veut dire que ??/??/ -> ?
Bravo, je crois (suis sûr) que tu as gagné ;-), j'ai relu la norme,
et c'est bien toutes les séquences de trigraphes qui sont remplacées, j'ai eu un soupcon dessus mais je me suis dit que ca ne pouvait pas arriver dans les chaines. ??/??/???? => ???? => ???? + le ' ' => le sizeof vaut bien 6.
Ce qui m'étonne, c'est que la conversion se passe en 2 temps : ??/??/ => puis => J'aurais pensé que la conversion des trigraphes était au même niveau que la conversion des caractères de contrôle et je me serais attendu à au final !
Yves ROMAN wrote:
Parce qu'il sait que sizeof("??/??/????") == 6
et il utilisera plutot sizeof("00/00/0000")
"??/??/????" -> ????
Sans doute une histoire de trigrammes, mais je ne les connais pas du
tout ....
Est-ce que ca veut dire que ??/??/ -> ?
Bravo, je crois (suis sûr) que tu as gagné ;-), j'ai relu la norme,
et c'est bien toutes les séquences de trigraphes qui sont remplacées,
j'ai eu un soupcon dessus mais je me suis dit que ca ne pouvait pas
arriver dans les chaines. ??/??/???? => \???? => ???? + le ' ' => le
sizeof vaut bien 6.
Ce qui m'étonne, c'est que la conversion se passe en 2 temps :
??/??/ => \ puis \ =>
J'aurais pensé que la conversion des trigraphes était au même niveau que la
conversion des caractères de contrôle et je me serais attendu à \ au final !
Parce qu'il sait que sizeof("??/??/????") == 6 et il utilisera plutot sizeof("00/00/0000")
"??/??/????" -> ????
Sans doute une histoire de trigrammes, mais je ne les connais pas du tout ....
Est-ce que ca veut dire que ??/??/ -> ?
Bravo, je crois (suis sûr) que tu as gagné ;-), j'ai relu la norme,
et c'est bien toutes les séquences de trigraphes qui sont remplacées, j'ai eu un soupcon dessus mais je me suis dit que ca ne pouvait pas arriver dans les chaines. ??/??/???? => ???? => ???? + le ' ' => le sizeof vaut bien 6.
Ce qui m'étonne, c'est que la conversion se passe en 2 temps : ??/??/ => puis => J'aurais pensé que la conversion des trigraphes était au même niveau que la conversion des caractères de contrôle et je me serais attendu à au final !
Targeur fou
Yves ROMAN wrote:
Yves ROMAN wrote:
Parce qu'il sait que sizeof("??/??/????") == 6 et il utilisera plutot sizeof("00/00/0000")
"??/??/????" -> ????
Sans doute une histoire de trigrammes, mais je ne les connais pas du
tout ....
Est-ce que ca veut dire que ??/??/ -> ?
Bravo, je crois (suis sûr) que tu as gagné ;-), j'ai relu la
norme,
et c'est bien toutes les séquences de trigraphes qui sont remplacées,
j'ai eu un soupcon dessus mais je me suis dit que ca ne pouvait pas arriver dans les chaines. ??/??/???? => ???? => ???? + le ' ' => le
sizeof vaut bien 6.
Ce qui m'étonne, c'est que la conversion se passe en 2 temps : ??/??/ => puis => J'aurais pensé que la conversion des trigraphes était au même niveau que la
conversion des caractères de contrôle et je me serais attendu à au final !
C'était pour expliquer la logique, il n'y a bien qu'une étape dans la conversion des trigraphes, au niveau du prepocessing. J'ai essayé avec sizeof("??/??/??/??/????"), qui me donne 7. Il est dit dans la norme que toute séquence de trigraphes est remplacée par le caractère de remplacement correspondant, et c'est l'unique phase pour les trigraphes. Si je reprend l'exemple "??/??/??/??/????", on devrait avoir après preprocessing "\????" comme chaine au niveau du source. étant le spécificateur de caractère d'échappement, la vraie chaine est '' '' '?' '?' '?' '?' '0'.
Par contre, sous Visual, en sortie préprocesseur (option /EP), je ne vois pas le caractère de remplacement des trigraphes quand ceux ci sont embarqués dans des chaînes.
Je vois bien les { } [ ] manquants, mais la chaine donnée à l'opérateur sizeof reste la même, j'aurais espérer que ce soit "\????", et je ne sasi pas si c'est normal. Qu'en est-il avec d'autres compilos ?
Regis
Yves ROMAN wrote:
Yves ROMAN wrote:
Parce qu'il sait que sizeof("??/??/????") == 6
et il utilisera plutot sizeof("00/00/0000")
"??/??/????" -> ????
Sans doute une histoire de trigrammes, mais je ne les connais pas
du
tout ....
Est-ce que ca veut dire que ??/??/ -> ?
Bravo, je crois (suis sûr) que tu as gagné ;-), j'ai relu la
norme,
et c'est bien toutes les séquences de trigraphes qui sont
remplacées,
j'ai eu un soupcon dessus mais je me suis dit que ca ne pouvait pas
arriver dans les chaines. ??/??/???? => \???? => ???? + le ' '
=> le
sizeof vaut bien 6.
Ce qui m'étonne, c'est que la conversion se passe en 2 temps :
??/??/ => \ puis \ =>
J'aurais pensé que la conversion des trigraphes était au même
niveau que la
conversion des caractères de contrôle et je me serais attendu à \
au final !
C'était pour expliquer la logique, il n'y a bien qu'une étape dans la
conversion des trigraphes, au niveau du prepocessing.
J'ai essayé avec sizeof("??/??/??/??/????"), qui me donne 7.
Il est dit dans la norme que toute séquence de trigraphes est
remplacée par le caractère de remplacement correspondant, et c'est
l'unique phase pour les trigraphes.
Si je reprend l'exemple "??/??/??/??/????", on devrait avoir après
preprocessing "\\????" comme chaine au niveau du source. étant le
spécificateur de caractère d'échappement, la vraie chaine est
'' '' '?' '?' '?' '?' '0'.
Par contre, sous Visual, en sortie préprocesseur (option /EP), je ne
vois pas le caractère de remplacement des trigraphes quand ceux ci
sont embarqués dans des chaînes.
Je vois bien les { } [ ] manquants, mais la chaine donnée à
l'opérateur sizeof reste la même, j'aurais espérer que ce soit
"\\????", et je ne sasi pas si c'est normal. Qu'en est-il avec
d'autres compilos ?
Parce qu'il sait que sizeof("??/??/????") == 6 et il utilisera plutot sizeof("00/00/0000")
"??/??/????" -> ????
Sans doute une histoire de trigrammes, mais je ne les connais pas du
tout ....
Est-ce que ca veut dire que ??/??/ -> ?
Bravo, je crois (suis sûr) que tu as gagné ;-), j'ai relu la
norme,
et c'est bien toutes les séquences de trigraphes qui sont remplacées,
j'ai eu un soupcon dessus mais je me suis dit que ca ne pouvait pas arriver dans les chaines. ??/??/???? => ???? => ???? + le ' ' => le
sizeof vaut bien 6.
Ce qui m'étonne, c'est que la conversion se passe en 2 temps : ??/??/ => puis => J'aurais pensé que la conversion des trigraphes était au même niveau que la
conversion des caractères de contrôle et je me serais attendu à au final !
C'était pour expliquer la logique, il n'y a bien qu'une étape dans la conversion des trigraphes, au niveau du prepocessing. J'ai essayé avec sizeof("??/??/??/??/????"), qui me donne 7. Il est dit dans la norme que toute séquence de trigraphes est remplacée par le caractère de remplacement correspondant, et c'est l'unique phase pour les trigraphes. Si je reprend l'exemple "??/??/??/??/????", on devrait avoir après preprocessing "\????" comme chaine au niveau du source. étant le spécificateur de caractère d'échappement, la vraie chaine est '' '' '?' '?' '?' '?' '0'.
Par contre, sous Visual, en sortie préprocesseur (option /EP), je ne vois pas le caractère de remplacement des trigraphes quand ceux ci sont embarqués dans des chaînes.
Je vois bien les { } [ ] manquants, mais la chaine donnée à l'opérateur sizeof reste la même, j'aurais espérer que ce soit "\????", et je ne sasi pas si c'est normal. Qu'en est-il avec d'autres compilos ?
Regis
cedric
PS: pour les courageux qui lisent mes posts jusqu'au bout, voici un petit test d'acuité visuelle : Pour quelles raisons ED ne doit-il pas utiliser le code suivant pour sa conversion de dates :
J'avoue chef, j'ai eu la flemme de tout lire, notamment je ne sais pas de quoi est fait ftimep. Mais par contre la réponse à la question doit être qu'il y a sûrement moyen de remplir ftimep avec des valeurs qui dépasseront la largeur MINIMALE spécifiée par %02d ou %04d...
Non ?
PS: pour les courageux qui lisent mes posts jusqu'au bout, voici un petit test
d'acuité visuelle :
Pour quelles raisons ED ne doit-il pas utiliser le code suivant pour sa
conversion de dates :
J'avoue chef, j'ai eu la flemme de tout lire, notamment je ne sais pas
de quoi est fait ftimep.
Mais par contre la réponse à la question doit être qu'il y a sûrement
moyen de remplir ftimep avec des valeurs qui dépasseront la largeur
MINIMALE spécifiée par %02d ou %04d...
PS: pour les courageux qui lisent mes posts jusqu'au bout, voici un petit test d'acuité visuelle : Pour quelles raisons ED ne doit-il pas utiliser le code suivant pour sa conversion de dates :
J'avoue chef, j'ai eu la flemme de tout lire, notamment je ne sais pas de quoi est fait ftimep. Mais par contre la réponse à la question doit être qu'il y a sûrement moyen de remplir ftimep avec des valeurs qui dépasseront la largeur MINIMALE spécifiée par %02d ou %04d...
Non ?
Antoine Leca
En <news:,Yves ROMAN va escriure:
Parce qu'il sait que sizeof("??/??/????") == 6
Ah oui !!!
Bravo à Oil de Lynx. Applaudissement nourri (?) de la foule en délire (??)
(Au début j'avais pensé que ça valait sizeof(char *) : je me fais avoir à chaque fois, alors j'ai fait le test...)
En pensant à mettre -trigraphs (ou à passer par le filtre TRIGRAPH de Borland), ce que manifestement ED a dû oublier...
Cela étant, alors que gcc 3.2 -W est silencieux sur le sujet (-Wall babille), gcc 3.4.2 signale le potentiel piège. Curieux (et bonne chose, en fait).
Antoine
En <news:42723055.2EB19156@NO.unilog.SPAM.fr>,Yves ROMAN va escriure:
Parce qu'il sait que sizeof("??/??/????") == 6
Ah oui !!!
Bravo à Oil de Lynx. Applaudissement nourri (?) de la foule en délire (??)
(Au début j'avais pensé que ça valait sizeof(char *) : je me fais
avoir à chaque fois, alors j'ai fait le test...)
En pensant à mettre -trigraphs (ou à passer par le filtre TRIGRAPH de
Borland), ce que manifestement ED a dû oublier...
Cela étant, alors que gcc 3.2 -W est silencieux sur le sujet (-Wall
babille), gcc 3.4.2 signale le potentiel piège. Curieux (et bonne chose, en
fait).
Bravo à Oil de Lynx. Applaudissement nourri (?) de la foule en délire (??)
(Au début j'avais pensé que ça valait sizeof(char *) : je me fais avoir à chaque fois, alors j'ai fait le test...)
En pensant à mettre -trigraphs (ou à passer par le filtre TRIGRAPH de Borland), ce que manifestement ED a dû oublier...
Cela étant, alors que gcc 3.2 -W est silencieux sur le sujet (-Wall babille), gcc 3.4.2 signale le potentiel piège. Curieux (et bonne chose, en fait).
Antoine
Antoine Leca
En <news:, Régis fou va escriure:
Par contre, sous Visual, en sortie préprocesseur (option /EP), je ne vois pas le caractère de remplacement des trigraphes quand ceux ci sont embarqués dans des chaînes.
C'est encore plus drôle que cela.
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.40904 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. char buf[sizeof("????")]; printf("taille : %lun", (unsigned long)sizeof("??/??/??/??/????"));
L'un est remplacé, l'autre pas ??? Autrement dit, ils doivent avoir deux logique de lecture des trigraphes...
À mon avis il doit y avoir des moyens de les coincer }:->
C'est-à-dire qu'il substitue le faux trigraphe à l'intérieur de FAUX (normalement phase 1), *après* avoir opérer la réunion de ligne du +fin de ligne (normalement phase 2), donc tout faux. Si quelqu'un peut reporter des bogues contre VC++ (j'ai testé la dernière bêta dispo), faites chauffer la colle!
On dirait que le bogue existe depuis pas mal de temps. MS C/C++ 7.0, la première version (92) qui semble savoir traiter les trigraphes, a déjà les mêmes problèmes. C 6.0a (91) a des problèmes pour démeler mon horreur, mais pour ton exemple donne déjà le même résultat que celui de la version 14 du compilo (buf avec la macro OK, sizeof du littéral pas de remplacement).
Bon, c'est pas tout cela, j'ai autre chose à faire que de corriger le code de 1991 de MS pour traiter les trigraphes ;-)
Antoine
En <news:1114783319.985921.294400@f14g2000cwb.googlegroups.com>,
Régis fou va escriure:
Par contre, sous Visual, en sortie préprocesseur (option /EP), je ne
vois pas le caractère de remplacement des trigraphes quand ceux ci
sont embarqués dans des chaînes.
C'est encore plus drôle que cela.
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.40904 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
char buf[sizeof("\????")];
printf("taille : %lun", (unsigned long)sizeof("??/??/??/??/????"));
L'un est remplacé, l'autre pas ???
Autrement dit, ils doivent avoir deux logique de lecture des trigraphes...
À mon avis il doit y avoir des moyens de les coincer }:->
C'est-à-dire qu'il substitue le faux trigraphe à l'intérieur de FAUX
(normalement phase 1), *après* avoir opérer la réunion de ligne du +fin de
ligne (normalement phase 2), donc tout faux. Si quelqu'un peut reporter des
bogues contre VC++ (j'ai testé la dernière bêta dispo), faites chauffer la
colle!
On dirait que le bogue existe depuis pas mal de temps. MS C/C++ 7.0, la
première version (92) qui semble savoir traiter les trigraphes, a déjà les
mêmes problèmes.
C 6.0a (91) a des problèmes pour démeler mon horreur, mais pour ton exemple
donne déjà le même résultat que celui de la version 14 du compilo (buf avec
la macro OK, sizeof du littéral pas de remplacement).
Bon, c'est pas tout cela, j'ai autre chose à faire que de corriger le code
de 1991 de MS pour traiter les trigraphes ;-)
Par contre, sous Visual, en sortie préprocesseur (option /EP), je ne vois pas le caractère de remplacement des trigraphes quand ceux ci sont embarqués dans des chaînes.
C'est encore plus drôle que cela.
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.40904 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. char buf[sizeof("????")]; printf("taille : %lun", (unsigned long)sizeof("??/??/??/??/????"));
L'un est remplacé, l'autre pas ??? Autrement dit, ils doivent avoir deux logique de lecture des trigraphes...
À mon avis il doit y avoir des moyens de les coincer }:->
C'est-à-dire qu'il substitue le faux trigraphe à l'intérieur de FAUX (normalement phase 1), *après* avoir opérer la réunion de ligne du +fin de ligne (normalement phase 2), donc tout faux. Si quelqu'un peut reporter des bogues contre VC++ (j'ai testé la dernière bêta dispo), faites chauffer la colle!
On dirait que le bogue existe depuis pas mal de temps. MS C/C++ 7.0, la première version (92) qui semble savoir traiter les trigraphes, a déjà les mêmes problèmes. C 6.0a (91) a des problèmes pour démeler mon horreur, mais pour ton exemple donne déjà le même résultat que celui de la version 14 du compilo (buf avec la macro OK, sizeof du littéral pas de remplacement).
Bon, c'est pas tout cela, j'ai autre chose à faire que de corriger le code de 1991 de MS pour traiter les trigraphes ;-)
