Jeu Videz votre presse-papier - Page 1030

Le nom de la vidéo est un clickbait, malheureusement je ne peux pas cliquer

Hop, double combo :
http://www.lefigaro.fr/elections/presidentielles/2017/04/28/35003-20170428ARTFIG00136-propos-negationnistes-jean-francois-jalkh-remplace-par-steeve-briois-a-la-tete-du-fn.php
http://www.huffingtonpost.fr/2017/04/28/jean-marie-le-pen-choque-par-lhommage-national-a-xavier-jugel_a_22059702/

Brunni > tu parles de mon post ? Pourquoi tu peux pas cliquer ?

parce qu'il est pas bait

2002, Jean-Luc Mélenchon à propos de l’abstention pic.twitter.com/uyNTa63Olg

— Ina.fr (@Inafr_officiel) April 28, 2017

Verdict (Adopté/Rejeté) ADOPTE

Xi > y'a 7 pages d'errata, c'est scandaleux

marrant le hardware encodeur de télémétrie, ca doit être un bonheur de faire le driver.

http://www.duckrace.lu/

----

Ils proposent des drivers pour RTEMS (non validés bien sûr), là c'est plutôt sur la partie télécommande que je me pète les dents

C'était quoi ça ? un extrait d'amicalement vôtre ?

*(int*)1 = 0; J'aurais jamais cru écrire ça un jour, sur TI

Mais à quoi tu joues ?

J'ai une lib qui contrôle un peu tout ce qu'on lui donne en mode debug. Quand elle choppe une connerie irrécupérable, elle affiche un message d'erreur, puis elle appelle le crash handler du kernel, tout simplement

Tiens, je me serais attendu à ce que tu utilises illegal pour ça ^^

Bien vu, même pas pensé, quelle honte !

Bah ^^

D'ailleurs j'y pense, même si tu voulais rester en C pur, je ne suis pas sûr que le code du ./30883 soit correct (flemme de relire le K&R en entier, mais ça ressemble à une situation indéfinie, ou en tout cas à du code dont les effets de bord ne sont pas évidents, donc potentiellement viré par l'optimisation du compilo). Il faudrait probablement écrire *(volatile int*)1 = 0; plutôt.

Ok, merci du tip, mais j'aimerais bien comprendre.
J'éspère que ça va marcher, j'aimerais bien éviter de mettre le nez dans l'assembleur généré pour vérifier, sinon je vais encore abandonner le projet...

Sur PC ce genre de code fonctionne avec Visual en tout cas, j'ai déjà testé

C'est une lib pour faire des guili-guili ?

informParentAboutReallocation

Zerosquare (./30888) :
Bah ^^

D'ailleurs j'y pense, même si tu voulais rester en C pur, je ne suis pas sûr que le code du ./30883 soit correct (flemme de relire le K&R en entier, mais ça ressemble à une situation indéfinie, ou en tout cas à du code dont les effets de bord ne sont pas évidents, donc potentiellement viré par l'optimisation du compilo). Il faudrait probablement écrire *(volatile int*)1 = 0; plutôt.

, en release ca sera optimized away

Pourquoi ? De quel droit se permet-il de dégager une écriture en RAM ? C'est clairement un bug. Bonsoir quand tu fais du baremetal et que t'écris ici ou là au boot...

Non c'est pas un bug, par contre c'est un piège vicieux et courant.

Tu es censé utiliser volatile si tu veux que les accès mémoire soient effectués de manière stricte, par exemple pour les registres hardware, les variables accédées à la fois par ton programme principal et une interruption, ou partagées entre plusieurs threads, etc. Dans le cas contraire, le compilateur a le droit de supprimer les accès mémoire qui n'ont pas d'effets de bord visibles. Tout le subtilité est dans le "visible", parce que ce n'est pas forcément évident pour le compilo. Théoriquement c'est gênant, en pratique c'est le prix à payer pour pouvoir faire des optimisations même basiques (sinon, même un simple index de boucle for ne pourrait pas être mis en cache dans un registre).

Je comprends pas. J'utilise pas une variable, mais une adresse directement.
- si je l'utilisais en lecture, je comprendrais le volatile, pour forcer la lecture à chaque boucle de for par exemple. En effet, ça pourrait être modifié par une interruption
- mais si je l'utilise en écriture comme ici, pourquoi devoir mettre un volatile ? Sinon, dans quel cas un volatile pourrait être inutile dans ce cas-là ??

La variable d'une boucle for c'est autre chose, ok je l'écris, mais je la lis aussi, pour connaitre la valeur de mon compteur. C'est donc important de savoir si elle n'est pas accédée par une autre variable, afin de pouvoir la mettre en cache dans un registre comme tu dis (ce qui serait impossible si la vériable était accédée de l'extérieur, en effet).
Que le volatile soit explicite dans un tel cas parait normal.

Mais peux-tu me donner un exemple ou une écriture en RAM pourrait foirer si elle n'était pas déclarée volatile ?

Je ne pense pas que le compilateur fasse la différence entre une variable et une adresse explicite. Tout ce qu'il doit voir, c'est que tu fais un accès en écriture à une adresse, mais qu'il n'y a jamais d'accès en lecture à la même adresse. Du coup, il considère ça comme une action sans effet et il peut la virer.

Tu pourrais objecter "si on écrit ce genre de choses, c'est qu'on a de bonnes raisons de le faire, donc ça ne devrait pas être supprimé", mais en pratique il y a des cas pas évidents. Ça peut par exemple être la conséquence d'un #define d'une constante à zéro, qui peut transformer un bout de code normalement utile en coquille vide. Sans compter que l'optimisation ne se fait pas que sur ton code original, elle peut aussi être consécutive à une optimisation précédente qui aura dégagé d'autres trucs.

D'une manière générale, le fait que la spéc du C laisse autant de liberté dans l'implémentation, ça n'est pas juste pour pouvoir supporter toutes sortes de matériels ; ça permet aussi que les compilos fassent des optimisations assez poussées. D'ailleurs, le compilateur peut tirer parti du fait que certains trucs sont considérés comme indéfinis pour optimiser agressivement, même quand l'archi sous-jacente a un comportement déterministe, et ça a déjà posé problème plus d'une fois. (C'est pas pour rien si je dis que le C n'aurait jamais dû être utilisé pour des applications où avoir un code correct est critique )

J'éspère que tu comprends que je vois ton argumentation comme très limite, même si tu défends très bien les compilateurs ?

=>

Zerosquare (./30899) :
- ça permet aussi que les compilos fassent des optimisations assez poussées
+ ça permet que les compilos fassent des optimisations sans trop se prendre la tête

et j'imagine que c'est ça qui provoque les déconnades dans les corner cases que tu évoques au paragraphe suivant.

Zerosquare (./30899) :
le compilateur peut tirer parti du fait que certains trucs sont considérés comme indéfinis pour optimiser agressivement, même quand l'archi sous-jacente a un comportement déterministe

C'est ça que j'appelle un bug. En l'occurence, ce que j'ai écrit a une sens très précis, et a une seule façon de s'écrire en code machine pour mon target. Si le compilateur décide de faire autre chose, c'est lui qui déconne, ou tout au moins la norme, mais pas moi.
Enfin, "pas moi" au sens pratique. Evidemment au sens formel, je suis censé me plier à la norme, même si elle ne colle pas à la réalité des machines.


ps-> un grand merci pour tes lumières.