OVH Cloud OVH Cloud

Probleme avec scanf

118 réponses
Avatar
Bakounine
bonjour

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.

Merci d'avance pour votre reponse.

8 réponses

8 9 10 11 12
Avatar
Antoine Leca
En <news:, Emmanuel Delahaye
va escriure:
Au fait -Wtrigraphs, c'est interessant ?


Oui (c'est le commutateur qui génère les avertissements), mais comme c'est
devenu un avertissement par défaut avec -Wall (et maintenant -W aussi),
l'option intéressante et à connaître ÀMHA c'est -Wno-trigraphs, pour faire
cesser le verbiage quand il y a des trigraphes dans ton code et que tu le
sais parfaitement.

À utiliser avec modération, évidemment.


Antoine

Avatar
Antoine Leca
En <news:d4tp71$1pi$, Charlie Gordon va escriure:
les digraphes que les experts du C99 ont cru bon de rajouter :-((.


Les digraphes viennent de C++, et en particulier de l'inventeur du langage,
un certain Bjarne Stroustrup.

Qui comme Danois est gêné de trouver des Æ ou autres ø quand il imprimait
des sources C ou C++ sur une imprimante qui traîne à portée de la main.


Les digraphes sont en fait beaucoup moins gênants que les trigraphes, le
seul vrai problème c'est le traitement des délimiteurs d'entêtes dans une
ligne #include qui peut devenir arbitrairement compliquée.


Antoine

Avatar
Emmanuel Delahaye
Antoine Leca wrote on 04/05/05 :
En <news:, Emmanuel Delahaye
va escriure:
"Emmanuel Delahaye" wrote in message
news:

September the 11th... ?

ISO 8601, normalisation des dates ?




Bravo Emmanuel. Heureusement qu'il y en a un qui suit!


Merci Google...

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"





Avatar
Harpo
Charlie Gordon wrote:


Le problème, c'est que le coût des bugs croit exponentiellement avec
le temps qu'on met à les trouver :

1: bug corrigé au moment de la frappe, par réflexe du programmeur bien
formé, attentif et éveillé :


Bien formé, attentif et éveillé : il faut donc 3 programmeurs.


10: bug corrigé car détecté par le compilateur (helas trop souvent le
compilateur n'est pas configuré pour signaler les cas suspects ou le
programmeur ignore les warnings : solution -Wall -W -Werror).


C'est une question de connaissances et de méthodes que tout le monde est
prêt à accepter.

Je suis globalement d'accord avec le reste.


Si les tests ne servaient à rien, on mettrait directement en fonction
sur un TGV les programmes dès qu'ils sont compilés, mais il faudra me
payer cher pour que je prenne un ticket.


Je ne dis pas que les tests ne servent à rien, loin de là ! Mais il
est
illusoire de s'imaginer qu'ils permettent de trouver tous les bugs.


Là encore, je suis d'accord, mais si les tests ne trouvent pas tous les
bugs (ça se saurait), ils peuvent permettre d'en éliminer une grande
partie

Or le management de projets informatiques semble le croire,


Vous avez bien dit "semble", je ne pense pas que quelqu'un de sérieux
aille au-delà de faire semblant.

alors que
les personnels qui produisent et conduisent les tests en question sont
bien souvent encore moins qualifiés ou motivés que ceux qui produisent
l'architecture ou le code des
systèmes.


C'est bien dommage, je n'y connais pas grand chose mais je pense
qu'élaborer des stratégies de test doit être intéressant. Il existe
aussi des produits qui analysent le code (je ne connais guère que leur
existence) et peuvent servir à des tests unitaires.

Quand ça se voit trop, l'argument massue est le manque de
moyens, et on obtient alors d'augmenter le nombre d'intervenants, ce
qui est une approche simpliste et souvent fatale du problème.


Je ne sais plus qui a dit qu'aux problèmes complexes il existait
toujours des solutions simples qui ne marchaient jamais.

Je ne connais pas l'embarqué mais j'imagine qu'on doit prévoir les bugs
et qu'il y a toujours un fallback dans ce cas. Par exemple dans le cas
d'Ariane 5, on l'a fait exploser en dernier recours, c'est quand même
mieux que de la voir s'écraser sur le WTC.
Evidemment, dans le cas d'un Airbus avec 500 personnes à bord, on peut
essayer de trouver mieux... j'sais pas ... demander s'il n'y a pas un
pilote dans l'avion...


Avatar
Antoine Leca
En <news:4271195b$0$1255$, Harpo va escriure:

Si les tests ne servaient à rien, on mettrait directement en fonction
sur un TGV les programmes dès qu'ils sont compilés, mais il faudra me
payer cher pour que je prenne un ticket.


C'est pas comme cela avec les versions x.0 de Micro$oft (et en général de
toutes les boîtes informatiques qui gagnent beaucoup d'argent, comme par
exemple mon fournisseur préféré de logiciel de @#*!): on met directement en
fonctionnement les programmes dès qu'ils sont compilés, ET il faut payer
très cher pour avoir un ticket ?

J'avais cru.


Antoine

Avatar
Antoine Leca
En <news:427b9eba$0$11695$, Harpo va escriure:
il y a toujours un fallback dans ce cas. Par exemple dans
le cas d'Ariane 5, on l'a fait exploser en dernier recours, c'est
quand même mieux que de la voir s'écraser sur le WTC.


Je ne connais pas le cas de la sûreté d'Ariane, mais je suppose qu'il n'y a
pas UN mais PLUSIEURS systèmes, indépendants et tout et tout, pour faire
sauter la fusée quand quelque chose n'est vraiment plus « nominal ».

Et que ces systèmes-là ont subi plus de tests que les autres.
Par exemple, je suppose que personne n'a eu l'idée « d'augmenter les
possibilités du sous-système d'auto-destruction en passant d'un micro 16 à
32 bits »; ou plus exactement, que l'on a gentiment expliqué à celui qui a
émis l'idée que « non, non merci, on a répliqué exactement le module qui
marche sur Ariane 3/4 ».


Antoine

Avatar
JBJ

En <news:427b9eba$0$11695$, Harpo va escriure:
il y a toujours un fallback dans ce cas. Par exemple dans
le cas d'Ariane 5, on l'a fait exploser en dernier recours, c'est
quand même mieux que de la voir s'écraser sur le WTC.


Je ne connais pas le cas de la sûreté d'Ariane, mais je suppose qu'il n'y
a pas UN mais PLUSIEURS systèmes, indépendants et tout et tout, pour faire
sauter la fusée quand quelque chose n'est vraiment plus « nominal ».

Et que ces systèmes-là ont subi plus de tests que les autres.
Par exemple, je suppose que personne n'a eu l'idée « d'augmenter les
possibilités du sous-système d'auto-destruction en passant d'un micro 16 à
32 bits »; ou plus exactement, que l'on a gentiment expliqué à celui qui a
émis l'idée que « non, non merci, on a répliqué exactement le module qui
marche sur Ariane 3/4 ».


Antoine
Bonjour,


Ça c'est pas toujours une bonne idée, voir :

<http://perso.wanadoo.fr/merlay/old/fusees/ariane5/qualification/page2.html>
<http://www-rocq.inria.fr/qui/Philippe.Deschamp/divers/ariane_501.html>
<http://www.lactamme.polytechnique.fr/Mosaic/descripteurs/Ariane501.01.Fra.html>


Cordialement.


Avatar
Antoine Leca
En <news:YX1fe.55679$, JBJ va escriure:

Et que ces systèmes-là ont subi plus de tests que les autres.
Par exemple, je suppose que personne n'a eu l'idée « d'augmenter les
possibilités du sous-système d'auto-destruction en passant d'un
micro 16 à 32 bits »;


Ça c'est pas toujours une bonne idée, voir :
[ les rapports sur l'échec du vol 501 ]


Je voulais dire, ne rien changer, même pas le système sur lequel cela
tourne. Pas question d'augmenter les performances d'un tel module, donc.

Ariane 501 a « correctement » explosée à la suite du bogue sur la conduite
de vol, je ne vois pas bien en quoi les références proposées s'appliquent.
Surtout que le vrai problème, c'est que le bogue est venu initialement d'un
système qui lui n'avait pas été testé avec la séquence de données réelles
(autrement dit, la fusée «devait» dévier dans 100% des cas).

Maintenant, si c'est pour faire remarquer que les logiciels conçus pour
gérer les pannes aléatoires (cas d'Ariane) ne doivent pas être exemptés de
savoir traiter *correctement* les pannes systématiques (défaillance qui est
la cause de l'explosion), alors là oui, d'accord.
Et c'est d'autant plus vrai pour les systèmes de sûreté, comme je voulais le
souligner.


Antoine


8 9 10 11 12