anaseto a écrit 2229 commentaires

C'est peut-là que les devs OpenBSD vont se mordre les doigts de ne pas vouloir jouer le jeu des embargos.

Je me demande si FreeBSD, NetBSD, DragonFly, etc. ont été eux prévenus.

Si mes souvenirs sont bons (je ne suis Perl 6 que de loin), Perl 6 considère que c'est des nombres rationnels et fait le calcul exact avec des fractions. Pour faire des calculs de flottants classiques (et donc performants), il faut lui dire explicitement, il me semble.

En effet, pas besoin de foutre en l'air la config par défaut pour que ce soit utilisable.

Ça fait plusieurs années que j'utilise bépo et vim avec la configuration par défaut (au sens, pour hjkl, le reste c'est du mnémotechnique donc la disposition clavier importe peu). En fait, on s'y fait très vite en bépo aussi, ce n'est pas grave que pour 4 raccourcis il n'y ait pas de logique, c'est toujours moins à apprendre qu'une disposition comme le bépo en entier, où il faut mémoriser la place (sans mnémotechnique, à part des trucs comme le fait que les parenthèses sont à côté) de plusieurs dizaines de touches. Et si ça reste gênant, faut se dire qu'utiliser d'autres moyens de se déplacer plus efficaces, comme e, b, f, t, }, ) etc., c'est de toutes façons le truc à faire, ou encore mieux, utiliser l'excellent vim-sneak ou bien easymotion ; pour les fans d'emacs, vu que c'est le sujet du journal, il y a des équivalents comme avy :)

Même parmi ceux qui ont une thèse (et ancien normaliens en prime), j'en connais qui donnent des cours au collège. La réalité, c'est qu'à moins d'être pacsé avec trois enfants, tu as très très peu de flexibilité pour choisir où tu vas. Et cela en bonne partie grâce au système d'ancienneté, qui fait que l'âge et la situation familiale sont le critère principal pour passer avant les autres, et non les compétences (l'exception étant un peu les prépas, où tout se fait sur dossier de manière non-transparente et indépendante du reste, du coup ils font un peu ce qu'ils veulent).

Les radiations de Fukushima n'ont entrainé la mort de personne à ce jour (les seuls morts liés sont liés au stress de la catastrophe et à l'évacuation de la zone sinistrée par le séisme).

Je suis surpris de la façon avec laquelle tu affirmes ça, ce n'est pas quelque chose de si simple à évaluer, il me semble, sur wikipédia toutes les études ne disent pas la même chose. Perso j'en sais rien, donc je ne me prononce pas, mais je te trouve très sûr de toi en disant « personne ». Et puis avant Fukushima il y a eu Chernobyl, et là les estimations sont aussi très variées et supérieures.

Malgré toute la crainte du nucléaire, le charbon, et le gaz (qui resteront nécessaires même en cas de 100% renouvelable pour assurer le pilotage du réseau) ont tué et tuent plus aujourd'hui que le nucléaire. Que ce soit dans les mines ou la pollution.

Tu as des sources fiables pour ceci ? Et qui prennent en compte le fait que, au niveau mondial, le charbon et le gaz produisent ensemble beaucoup plus d'énergie électrique actuellement que le nucléaire (source, 10.9% en 2012, contre 16.9% rien que pour l'hydroélectrique, le reste étant gaz et pétrole et charbon). C'est une étude, en plus, difficile à mener, et qui mettrait de côté la question des déchets et des centrales vieillissantes (phénomène récent), de toutes façons.

Mais même si c'était le cas, il faut être conscient que le nucléaire au niveau mondial ne représente déjà pas grand chose pour ce qui est de l'électrique, mais il ne représente presque rien pour ce qui est de l'énergie en général : selon wikipédia, c'est 4%, moins que l'hydroélectrique à 7%, donc j'ai du mal à voir pourquoi on en parle autant comme d'une solution, même en mettant de côté tous ses dangers.

Bref, le seul truc objectif qui, à mon avis, pourrait faire baisser significativement la part du pétrole, charbon et du gaz, c'est juste qu'on consomme moins, ça demande un effort et surtout pas qu'on perde du temps à se demander s'il faut faire plus de nucléaire (alors que ça stagne depuis longtemps), on n'en a pas les moyens à grande échelle, c'est juste un solution (pour l'électrique uniquement) pour un petit nombre de pays, si on peut appeler ça une solution, avec de plus des risques difficiles à évaluer ou prévoir.

Je dirais même qu'on voit bien que kantien a fait exprès de tout changer sauf les dates, les noms et le nom du vainqueur. Si ça c'est pas une astuce pour camoufler son acte, je sais pas ce que c'est !

Cela me semble vain de monter une campagne de financement pour ma pomme, quand tant d'autres personnes dont les contributions sont bien plus visibles et concrètes peinent à récolter du soutien.

C'est compliqué, oui. Dans l'idéal, au fond, on voudrait le revenu universel ou quelque chose comme ça mais, comme ça n'a pas l'air évident à faire passer comme truc, on cherche des initiatives pour rémunérer des projets libres.

En fait, ça vaut pour tout plein d'autres types de projets du moment qu'ils n'ont pas de modèle économique viable évident dans notre système actuel ; et d'ailleurs, pas trop non plus dans les systèmes précédents, ça fait des centaines d'années que par exemple les artistes ont surtout (sur)vécu de mécénat, un travail à côté ou maintenant le rsa. J'en sais quelque chose, j'ai une sœur qui écrit des romans (dont une dizaine libres) et qui s'est bien rendu compte que le rsa ça allait rester sa principale source de revenu pour un bon moment très probablement. Une remarque que je me suis faite en lien avec les modèles économiques, c'est que dans le logiciel, par rapport aux artistes, parfois on a l'impression que c'est plus facile d'obtenir un revenu si on fait des efforts, mais du coup on est plus tenté de ne pas choisir au final librement à quoi on contribue, quand, ni comment. J'avoue que l'idée de faire le choix de la pauvreté si ça peut me faire gagner du temps et de la liberté trotte dans mes idées depuis quelques temps.

PS : je suis passé par ton site et j'ai lu quelques chapitres d'une de tes histoires, et ça m'a semblé plutôt sympa et bien écrit :) Et points bonus pour les leçons de lojban aussi :) J'avais lu Alice au pays des merveilles en lojban l'année dernière, j'en ai plus fait beaucoup depuis, mais c'est sympa.

Bien sûr, rien ne l'oblige à prendre position, mais il passe ainsi à côté (probablement volontairement) du cœur du problème : qui est l'utilisateur du code, en réalité? Est-il acceptable de permettre à nos machines d'exécuter du code sans que nous n'ayons aucun contrôle sur celui-ci?

On peut se dire que le combat pour éviter qu'Intel continue à mettre cette horreur de ME dans les machines est orthogonal à l'OS utilisé lui-même. Ça n'enlève donc pas l'intérêt de savoir qu'ils utilisent Minix qui a l'air d'être de bonne qualité, plutôt qu'un truc potentiellement plein de bugs et propriétaire dont on ne saurait rien :)

le compilateur peut choisir n'importe quel comportement possible en accord avec la norme en cas de non déterminisme; c'est sur ce point que je n'ai pas bien compris si le choix de clang est acceptable

Je ne suis pas sûr de te suivre : le non déterminisme (plusieurs choix) est une chose différente des comportements indéfinis (sémantique bloquante). Ici je sais pas si c'est vraiment un comportement indéfini ou non, par contre. Mais une des premières choses que fait CompCert, c'est de faire un choix pour tous les non-déterminismes de C, afin de faire en sorte que tous les langages intermédiaires suivants soient déterministes, ce qui simplifie pas mal certaines choses.

Je m'aperçois par contre que j'ai tourné cette phrase à l'envers :

alors un des comportements possibles du source correspond à une « amélioration » de ce comportement

C'est le code compilé qui est une « amélioration » est pas l'inverse, mais j'imagine que tu avais bien compris :)

Je ne connais pas bien la sémantique du C mais, pour l'exemple du journal, il me semble bien que l'optimisation de clang ne respecte pas ces principes.

Si l'exemple du journal correspond vraiment à un comportement indéfini, alors le théorème de CompCert ne dit rien à son sujet, a priori :

Theorem transf_c_program_preservation:
  forall p tp beh,
  transf_c_program p = OK tp ->
  program_behaves (Asm.semantics tp) beh ->
  exists beh', program_behaves (Csem.semantics p) beh' /\ behavior_improves beh' beh.

En traduction, ça veut dire que si le code compilé a un certain comportement, alors un des comportements possibles du source correspond à une « amélioration » de ce comportement (ce qui fait écho à ton commentaire). Par contre, s'il y a un comportement indéfini du source, donc sémantique non définie, je pense pas que ça dise quoi que ce soit d'utile (on obtient juste un comportement « go wrong » accompagné d'une trace dès que la sémantique bloque, donc au mieux ça dirait peut-être que jusqu'au moment où ça bloque la sémantique est préservée).

Ok, cet -Ofast fait un peu peur, mais le message précédent de Renault laissait sous-entendre ceci pour -O2 et -O3, alors que j'aurais pensé que ceux-ci, contrairement à -Ofast, profitent uniquement des comportements indéfinis (de manière plus ou moins agressive et risquée), mais respectent la sémantique du moment qu'elle est définie au sens du standard (le message de Renault ci-dessus me laisse penser que c'est ce qu'il voulait dire). Quand elle n'est pas définie, la notion de ne pas la respecter n'est pas vraiment définie, si je puis me permettre :)

Je découvre ça moi aussi o_O Pour moi, les -O0, -O2, -O3, etc. correspondaient juste à des usages et compromis différents : debug, compilation plus ou moins rapide, taille du binaire vs performances, optimisations plus ou moins risquées (parce que plus l'optimisation est complexe, plus il y a des risques de bug dans le compilo), mais dans tous les cas il s'agissait de respecter le standard.

C'est ce que j'utilise pour shmuprpg :-)

Arf, je suis mort :)

Oui, il y a un warning (mais du coup ça c'est le compilo, pas le standard), mais je me dit surtout que c'est pas vraiment un pointeur nul, mais plutôt un pointeur non initialisé, en effet.

En plus marrant, il y a :

int main(void) {
    int *p;
    *p = 3;
    if (*p == 3) {
       return 0;
    }
    return 1;
}

Qui renvoie 0 avec -O2 et crashe avec -O0.

Que je sache, de manière générale, déréférencer le pointeur null est indéfini. C'est que qui permet, par exemple, dans:

int main(void) {
    int *p;
    *p = 3;
    return 0;
}

au compilateur de justifier d'enlever p vu qu'il n'est pas utilisé, ce qui fait qu'au lieu d'avoir un crash ou une écriture à l'adresse nulle (les deux comportements intuitifs que tu mentionnes), il termine et renvoie 0.

Le problème c'est que tu ne sacrifie pas "un peu" mais "énormément" en perf.

C'est peut-être le cas parfois, mais je doute que l'exemple que tu donnes (les bound-checks pour les tableaux), on soit dans l'« énormément » pour la plupart des logiciels : dans les trente dernières années les prédicteurs de branchement ont quand même fait beaucoup de progrès dans les CPU, et là c'est un cas particulièrement bien traité normalement. Et même sans ça, c'est significatif seulement si le something se fait très rapidement, donc calcul scientifique ou analogue probablement. Donc je demande un bench :) Idéalement il faudrait un « on a rajouté des bound-checks dans tel programme C, et maintenant c'est XXX% fois plus lent/gourmand en espace », avec la condition que le programme soit pas du calcul scientifique ou quelque chose de similaire.

Par contre, les bounds-check risquent de compliquer l'analyse du programme et de gêner significativement d'autres optimisations.

À la limite, vous pouvez blâmer Clang de supposer que votre programme est correct.

Mais c'est exactement ça dont il s'agit : le compilateur peut faire comme si il n'y avait aucun comportement indéfini dans le programme, et donc pouvoir optimiser plus facilement au risque d'avoir des mauvaises surprises, ou il peut choisir de faire n'importe quoi d'autre en cas de comportement indéfini et, en particulier, choisir le comportement le plus sûr, le moins suprenant et le plus proche de ce que voulait probablement le programmeur.

Un certain nombre de comportements indéfinis du C/C++ sont des reliques historiques liées à des problèmes de portabilité vers des architectures qui n'existent plus, ou aussi liées au fait que la technologie des compilateurs en était à ses débuts à l'époque, que les ordis étaient beaucoup plus lents et que donc rendre faciles les optimisations était quelque chose de beaucoup plus important qu'aujourd'hui.

On peut donc interpréter « indéfini » par : on ne peut pas faire la même chose sur toutes les archis pour ça, donc on a besoin d'un peu de flexibilité, ou bien, on ne sait pas encore écrire telle optimisation de façon efficace avec la contrainte que tel comportement indéfini doit être traité de façon sûre, donc on prend le risque.

Un "mix" des deux sur l'implémentation de base pas faites : les persos pourraient se déplacer au bon vouloir tant que pas d'ennemi en vue, puis si l'on en rencontre un, on passe en mode tour à tour avec jets d'initiative pour déterminer l'ordre de jeu.

Ça me rappelle un peu des choses que j'ai lu sur javelin, écrit en Java aussi, qui utilise un système d'initiative, mais que j'ai malheureusement pas pu tester pour de vrai, parce que j'y connais rien aux systèmes de build Java et qu'il n'y a pas d'instructions, donc j'ai eu un peu la flemme :)

Mais bon, faut ça, sinon ça fait pas moderne ! :)

Les interfaces ASCII ou simples avec des tuiles sont atemporelles, du moment qu'elles sont un minimum intuitives :) C'est l'avantage par rapport aux jeux 3D triple A, qui après une dizaine d'années ont l'air tout vieillis ;)

des langages qui sont devenus en pratique, sur certains aspects critiques, débiles.

Mais est-ce le langage en soi, ou l'implémentation ? Pour prendre un exemple, les dépassements d'entiers signés, comportement indéfini, à l'origine c'était parce qu'il y avait, suivant les architectures, quelque chose comme trois façons d'implémenter ça. Aujourd'hui il me semble que tous font la même chose, donc le comportement serait facile à définir, mais même en supposant qu'il y a trois ou plus possibilités, entre « tout peut arriver » et « un comportement parmi trois possibles peut arriver » il y aurait une différence. Mais, en pratique, les compilateurs se permettent d'interpréter ce comportement indéfini pour déduire des choses comme que x + 1 > x est vrai, qui sont plutôt des dérives d'implémentation optimisante que des choses auxquelles auraient pensé comme normales les gens qui écrivaient le standard à l'époque, j'ai l'impression.

Ou alors passer à des langages moins débiles.

Étant donné que pour une raison ou une autre (historique ou non), il y a beaucoup de programmes écrits en C/C++ qui n'ont pas besoin de performances extrêmes, mais qui par contre bénéficierait d'un comportement plus sûr, un compilateur qui élimine les comportements indéfinis, quitte à être moins performant, c'est intéressant : réécrire tous ces logiciels (si tant est que ce soit toujours possible) est peut-être plus laborieux qu'adapter un compilateur pour ajouter des checks au runtime et éviter les optimisations qui utilisent les comportements indéfinis.

Intéressant, merci pour le lien !

Je veux dire, est-ce qu'il y a eu des initiatives pour faire un compilateur qui donne une sémantique à tous ces comportements indéfinis, quitte à sacrifier un peu en performance, avec crash assuré quand il ne peut pas faire mieux ? Parce que même CompCert (prouvé en Coq) pour C ne donne pas de garanties s'il y a des comportements indéfinis pour lesquels la sémantique bloque (même si le compilo essaie en pratique d'éviter d'être trop intelligent, j'ai l'impression, mais le théorème ne dit rien sur ça).

Sauf qu'il est possible que les auteurs aient donner leur accord de peur qu'OpenBSD publie le patch avec les explications de la faille, ce qui aurait été pire question embargo.

C'est plus une illustration de ce que la peur dans le secret peut conduire à faire comme extrapolations et erreurs humaines, qu'un argument pour faire culpabiliser OpenBSD, qui de mon point de vue, a juste permis de mettre en lumière dans le cas d'une faille non critique qu'il ne faut pas grand chose (juste se plaindre par mail) pour parfois réussir à faire faire des bêtises au propre initiateur de l'embargo, erreur qu'il reconnaît lui-même et qui montre que le secret dans ce genre d'embargos ne tient qu'à un fil et, entre-temps, tout le monde est dans le doute dans une atmosphère de méfiance, se demandant si une bêtise similaire ou fuite a déjà été commise ou non.