Le Sun, 16 Oct 2011 04:11:45 -0700 (PDT), Jean-Christophe écrivait :
Si tu veux !
Je suis très bon au lancé de SS20, tartagueule après ça !
Sérieusement ? Ta libc bufferise les I/O. Elle les traite lorsqu'elle a le temps (lorsque ton processeur fait les pieds au mur) ou quand on lui demande gentiment (avec un fflush(whatever)). Sous DOS, il y a de fortes chances qu'elle soit synchrone. Sous Windows, à mon avis, pour des raisons de comptabilité avec des vieux softs qui faisaient l'hypothèse d'I/O synchrones, il y a de forte chance aussi qu'elle soit synchrone. Sous Unix, c'est juste faux. Personnellement, pour ne pas avoir de problèmes, je colle toujours un fflush() lorsque je veux être sûr que les buffers soient effectivement vidés.
Par ailleurs, fflush() existe déjà en C89. Attention, un piège amusant est que fflush() vide les tampons en espace _utilisateur_. Si tu veux aussi les vider en espace noyau (par exemple pour des choses tournant autour des disques), il faut ajouter sync() ou fsync().
Essaie la même chose sur un système multitâche. Tu risques d'avoir de grosses surprises ;-) Je ne disconviens pas que 99% du temps, ça fonctionnera, mais le 1% restant risque de te poser problème...
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Sun, 16 Oct 2011 04:11:45 -0700 (PDT), Jean-Christophe écrivait :
Je te propose le pistolet à 15m et l'épée. Personnellement, je prends le pistolet, je te laisse l'épée. Rendez-vous à 15 heures devant l'espèce d'horreur moderne devant l'École Militaire ! ;-)
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Alea jacta est, fluctuat nec mergitur, et caetera.
Palsambleu, cela contrarie les r=E8gles de la Chevalerie ! D=E9gott=E9 aux puces de Montreuil, ou de Saint-Ouen ?
.
Comme je l'ai dit, une carte =E0 uC et un compilo C avec par exemple la lib d'un afficheur LCD ne va pas faire ce genre de choses. Ca reste simple ( simplet si tu pr=E9f=E8res ) C'est pour cela que je pense qu'il faut distinguer le printf() du C, et le syst=E8me - s'il y en a un - sur lequel ca tourne.
s vieux
te
urs
=E8ge
.
Bon, ok.
d'avoir
=E7a
Oui, bien recu. Comme je n'ai jamais eu ce probl=E8me, je croyais que. Merci pour la le=E7on.
Le Sun, 16 Oct 2011 05:59:03 -0700 (PDT), Jean-Christophe écrivait :
Mais seulement dans les rues en pente !
Dégottées directement chez feu Monsieur Sun.
Non, _rien_ ne te l'assure. Lorsque tu appelles printf(), tu appelles en fait (par macro interposée ou fonction inline) un certains nombre des choses imbriquées. Généralement, ça donne ceci :
Le printf() n'est _pas_ une fonction intrinsèque du compilo. C'est même pour cela que tu as besoin d'inclure stdio.h et stdlib.h. Plus exactement, rien ne te garantit que ce soit une fonction intrinsèque du compilo. Un autre piège amusant est d'oublier que printf() peut être une macro, mais on va éviter les subtilités du style printf("%s", ptr++) qui peut être assez casse gueule. Je sais que ce truc n'arrivera ni avec gcc, ni avec VC++. Mais dans le cas général, c'est à proscrire, parce que, en C89 qui ne connaît pas inline, ça pourrait bien terminer en :
write(FILENO_STDOUT, ptr++, strlen(ptr++));
qui est une expression qui contient un méchant effet de bord !
Pour revenir au sujet qui nous intéresse. ton compilo n'a aucune raison de savoir si ton printf() est ou n'est pas synchrone. Tu n'as aucun moyen de le maîtriser le déroulement des opérations dans la libc (contrairement à Motif, où tu peux forcer la libXm dans un mode synchrone). En d'autres termes, même dans un environnement monotâche, tu peux avoir une libc qui bufferise et qui n'envoie tes informations à la console que lorsqu'elle en a envie (c'était une pratique de la libc du compilo C TSC tournant sous Flex-9 qui affichait la sortie standard quand il y avait plus d'une ligne [80 caractères] à afficher et elle affichait ligne par ligne.). Croire que le comportement synchrone est un dû est une erreur de programmation. Enfin, c'est toi qui vois.
Personnellement, je me tape du C depuis une grosse vingtaine d'années. Durant tout ce temps, j'ai eu l'occasion de corriger pas mal de code (du style de ceux des thésards que j'encadrais). Je suis tombé comme tout le monde (et je tombe encore de temps en temps) sur des subtilités de la norme C. Que ceux qui n'ont jamais écrit de telles bourdes me lancent la première pierre. Néanmoins, il y a un certain nombres d'erreurs que je ne fais plus et mon expérience me dit que la plupart des erreurs non reproductibles dans un programme en C qui ne vient pas d'erreur de mémoire vient de ces préjugés. C'est aussi entre autres pour cela que j'ai écrit mon propre langage de programmation à l'usage de mon labo.
Naon !
J'espère bien ! ;-)
De rien, aujourd'hui, c'était gratuit ;-)
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
| je te laisse le choix des armes. | (Silex, Quatrains, Piolet, Octo-syllabes, Katana, Vax ...)
:oD
J'y aurais pr=E9f=E9r=E9 Une joute verbale, Des improvisations Tout en circonstances Et par tirage au sort Quand au nombre de pieds ; Las, qu'esp=E9rais-je donc De l'honneur d'un Vilain ?
Ce n'est pas =E9quitable : Vous me verrez de loin Avec mon Katana ; Mais pour moi, comment donc Vous reconnaitrais-je ? Armoiries du cheval, Ou plume au couvre-chef ?
Mais enfin brisons-l=E0, D=E9ja mes gens att=E8lent Mon carrosse c=E9ans. Pr=E9parez vos abbats, A ce qu'il leur en cuise. Qu'il n'en tienne, tout est dit.
D=E8s que vous me verrez : Tirez donc le premier, Cher Messire JiKaB=E9 !
Mais s'il s'agit d'un lancer d'une station Sparc, m=EAme =E0 mon =E2ge j'aurai bien le temps d'esquiver.
Si, parce-que - dans ce cas - c'est *moi* qui code le comportement en aval de printf(), j'y suis bien oblig=E9, sinon comment veux-tu que le truc sache comment s'y prendre, vu qu'il n'a aucune id=E9e du format, ni des ports de sortie, etc ? Sous DOS ou Windows ou autre je te crois volontiers, mais ce que je d=E9cris est totalement diff=E9rent.
onne ceci :
est
Plus
=E8que
eut
ue ce
n :
Evidemment, l'usage de pr=E9 ou post incr=E9mentation dans une macro c'est du casse-pipe garanti.
Sinon, personnellement je ne flush() que les sorties fichier, et uniquement quand j'ai besoin d'=EAtre s=FBr que ca se fasse =E0 un endroit voulu de mon programme.
e raison
un
libc
de synchrone).
peux avoir
nsole que
ilo C
l y
ichait
s.
Oui, j'entends bien et j'acquiesce tr=E9s volontiers, mais tu persistes =E0 ignorer les cas o=F9 un printf() est =AB d=E9rout=E9 maison =BB par le programmeur. ( d=E9ja je t'entends d'ici marmonner qu'=E0 ce moment-l=E0 ce n'est plus du printf standard C ... oui, mais bon. )
pas
suis
) sur
de
a un
me
me
=E9s.
ngage
L=E0, c'est s=FBr qu'il n'y a pas mieux.
A une =E9chelle plus modeste, il y a quelque temps d=E9ja je m'=E9tais fait un compilo maison =E9crit en C, pour un langage maison (que j'ai nomm=E9 C-- :o) pour faire facilement du calcul sur des quaternions avec de TRES belles sorties 3D gr=E2ce au merveilleux OpenGL. En nettoyant correctement les sources, je trouverai bien =E0 caser ca dans un projet pro, parce-que ca en jette un max.
M=E9ssie ! Je dis cela justement parce-que sur une carte uC sans OS c'est *moi* qui me tape l'envoi des chars vers le LCD par un d=E9tournement du printf() qui remplit un buffer RAM, qui en aval sera vid=E9 par une interruption, alors je sais pertinemment que dans ce cas il n'y a aucune, mais aucune obligation de '\n' pour envoyer les chars.
Ben tiens : je ne tiens pas =E0 ce que, pour enfoncer le clou, en un click tu coupes l'alimentation r=E9seau de mon arrondissement.
Bon, ce n'est pas aujourd'hui que je vais me faire embaucher :o) Mais si tu tiens =E0 =EAtre r=E9tribu=E9 pour toutes ces informations, tu peux te payer sur une avance de mon futur salaire :oD
Evidemment si on fait sa propre cuisine non standardizé, on peut tout faire. Moi j'ai (il y a longtemps...) joué sous OS9/Linux et j'ai donné ! J'ai appris entre autre à faire suivre un printf "urgent" par un fflush... Me rappelle de notre desarrois la premiere fois que cette tuile nous est tombée dessus. Mon pote qui etait orienté plus software que hardware avait bien sur immediatement rajouté le fflush de la mort qui tue qui va bien...Pfff...Pas trop intuitif toussa c'etait..
| j'aimerais assez bien qu'on m'explique | la diff=E9rence entre C et Pascal
Comment faire confiance =E0 un langage qui indexe le premier =E9l=E9ment d'un tableau par le chiffre 'un' ? ( c'est vrai que l'invention du z=E9ro par les Indiens est officiellement dat=E9e vers le Ve si=E8cle, mais quand m=EAme ! )
Et il y a toujours des gens qui doivent subir Delphi.
Il suffit simplement de se dire que ca ne pourrait pas =EAtre pire, pour que ca le devienne effectivement.
Fais gaffe, mon killer robot programmé en Modula 2 est muni de tronçonneuses, de lance-flammes et de plein d'autres choses qui piquent. Et lui il n'a pas besoin d'un flush pour commencer à attaquer les infidèles. :p
Pourquoi es tu si affirmatif, à dire "N importe quoi" dès le premier message ? Tu as codé personnellement le code qui fait la mise à jour ? Tu as testé ce truc dans toutes les configurations possibles ? Non ? Bon alors, de quoi tu t'occupes ?
Je te jures - je l'ai vu de mes yeux - que le truc s'est mis à jour (un downgrade en fait) et que nos photos n'étaient plus présentes après ça. Et nous n'avons cliqué sur rien du tout mis à part la mise en route d'itunes, la seule chose préoccupante avant le constat de la non-présence de ce qu'on voulait justement récupérer, c'était que ce soft était en train de ramer totalement, sûrement pendant qu'il écrasait le contenu de l'iphone... sans rien demander. Je crois qu'il nous a juste dit ce qu'il a fait quand il avait fini. Apparemment, le machin avait été mis à jour avec un autre ordinateur/itunes et celui là n'a pas aimé ce changement et à remis la config qu'il connaissait (et du coup mon hote à retrouvé les anciennes photos d'avant sa mise à jour).
Tu peux très bien me dire "ouais mais chez moi ça n'a pas fait ça", mais l'absence d'un phénomène n'est pas la preuve que le phénomène ne peut pas se passer.
Note que ce n'était pas mes ordinateurs, ni mon téléphone, parce que d'une part jamais je n'utiliserai de telles daubes, et que de l'autre, j'aime bien garder la main sur mes systèmes. Et ce que je vois de temps en temps ne me conforte que plus dans mon choix d'utiliser un vrai APN quand je veux faire des photos, et un vrai téléphone (en tout cas pas un téléphone Apple) quand je veux téléphoner.
Fin du HS de mon coté. Il est mort, et personnellement, je ne le pleurerai pas.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.