C'est dommage que l'article n'explique pas plus de quoi il s'agit. Il va falloir aller faire une petite excursion pour comprendre avant d'en dire plus...le renversement d’une constante
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
C'est dommage que l'article n'explique pas plus de quoi il s'agit. Il va falloir aller faire une petite excursion pour comprendre avant d'en dire plus...le renversement d’une constante
J'ai lu la suite de la conversation, et j'ai pas l'impression que Linus soit dans un accès de rage folle et incontrôlable.
Personne le prend mal, ça semble admis que le code pointé du doigt était mauvais et personne ne se sent offusqué blessé ou agressé.
C'est franchement tout un fromage pour pas grand chose, si le code est pourrit le code est pourrit, et si les gens (Linus et les gens de chez GCC, et de linux) sont suffisamment proche pour pouvoir utiliser ce niveau de langage je vois pas ce que ça peut nous faire.
C'est le discours à la mode à San Francisco cette année mais il suffit d'observer un instant le monde pour voir que c'est faux.Envoyé par Mr_Exal
C'était bien entendu une hyperbole, mais beaucoup de geeks sont assez fortunés ou influents pour pouvoir peser dans la balance mondiale, après il n'y a pas que des geeks et fort heureusement (sans diversité qu'est ce qu'on se ferait chier.. Vous imaginez pas pouvoir spoiler tel série ou tel film ? Quelle horreur !)
En revanche, je pense que la culture geek est maintenant bien ancrée dans la culture populaire, il suffit de voir TBBT, Game of Thrones, etc (merde j'aurai dû faire mon mémoire là dessus ^^).
L'homme est un fou pour l'homme. Toi qui viens de me mettre unaie au moins le courage d'expliquer pourquoi tu n'es pas d'accord.
Linus Torvalds a bien raison de se manifester ainsi et de mettre le projecteur sur des erreurs importantes.
Il y aurait beaucoup à dire aussi de certaines distributions Linux (pas du noyau) qui tentent de ressembler à Windows 8
J'ai toujours préféré le franc parler au consensus et à la langue de bois !
Quant à l'excellent GCC (g++) dont j'utilise la version 4.7 actuellement pour le C++11, il sera corrigé et tout rentrera dans l'ordre.
Il peut avoir raison sans s'emporter comme un gamin de "maternelle" (pour reprendre son expression).
Il est très en avance technologiquement mais très en retard émotionnellement. Ca s'appelle de l'autisme
On connait tous le caractère "spécial" de ce gars là....il est vraiment stupide de réouvrir ce débat inutile stérile et sans aucune influance sur lui, sur ce forum à chaque coup de gueulle.....Aucun d'entre vous ne le connais personnellement donc aucune influance.... ça sert à rien....
enfin si ça peut faire sourire à la limite parfois....
De plus il s'agit d'une quasi-constante chez les grands développeurs.....Il y en a d'autres qui ont aussi des sacrés coups de gueule dans le Monde BSD, dans le monde linux, et même dans le monde du logiciel proprietaires....
Le problème, c'est que plus un outil est bas-niveau, plus il se doit d'être fiable.
Oui, j'ai déjà dû chercher un bug qui était issu du compilateur (gcc aussi pour ne pas le nommer), et je peux vous assurer que c'est vraiment la merde, et qu'à part les jeunes diplomés, personne ne remet jamais en cause le compilateur, ce qui rend les recherches encore plus difficiles.
Après, la manière de le dire "à la Torvalds", je trouve pas ça top, mais bon.
On a tous eu un jour ce genre de soucis, moi c'est avec le compilo de Embarcadero (une fonction qui comptait plusieurs arguments, si le premier était une String, c'est NULL qui t'arrivait dans la fonction...Builder c++ 2010, et seulement en convention __fastcall, génial le bug !). mais bon, j'm'emporte pas comme un demeuré, qui n'a jamais fait de bug dans un programme, ça arrive.
Sans compter le matériel buggé : exemple le bug de la division du Pentium. Et dans un passé plus lointain, le bug du contrôleur UART 8250 (contrôleur interface RS232 sur les pc d'origine). Celui-ci était buggé. Les bugs étaient contrecarrés dans le BIOS. La puce 8250A corrigeait les bugs mais n'était plus utilisable dans les PCs (les BIOS n'étant pas flashable a l"époque). Le constructeur a alors sorti une nouvelle puce, la 8250B, réintégrant les bugs.
Combien de ligne de code contient GCC ? c'est énorme. Mais les conséquences d'une "coquille" aussi.
Au fur et à mesure de l’évolution, le code s'étoffe et se complique, le risque de bug augmente. Mais en tout cas il a été trouvé, donc il sera corrigé. Par ailleurs, GCC est fait par des bénévoles est gratuit ne contient ni plus ni moins de bugs qu'un équivalent payant (sans tenir de comptabilité), mais le système de contrôle des modifs, la réactivité du monde libre m'impressionne surtout du fait que c'est gratos.
Comme l'a fait remarquer frp31, qui n'a jamais dit "c'est de la merde..." en rencontrant un dysfonctionnement. En tout cas pas moi. On a tendance à plus être marqué par les dysfonctionnement que le fonctionnement "normal" finalement quotidien avec quelques aléas.
Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
Mon article sur le P2V, mon article sur le cloud
Consultez nos FAQ : Windows, Linux, Virtualisation
A toujours convoiter la dernière version d'un logiciel, on finit par en essuyer les plâtres.
Je ne crois pas que ce soit une preuve d'intelligence que d'avoir la témérité de systématiquement choisir la dernière version d'un compilateur. C'est prendre des risques de régressions pour bien moins de bénéfice fonctionnel.
Et des bugs de compilateur, il n'y a pas que gcc. J'en ai connu sur le compilateur Sun C++ et sur HP Fortran. C'est particulièrement inattendu et déroutant.
Mon avis..
Le noyau Linux est le plus utilisé dans le monde, toutes machines confondues.
Linus est le leader du développement de ce projet.
Cela fait de lui un homme doté d'une responsabilité à l'enjeu planétaire. Il doit être constamment sous pression pour pouvoir assumer une telle responsabilité.
C'est donc normal qu'il pète un plomb à certains moments !
Réfléchissez et comparez ce qu'il a dit à un certain Nicolas S. qui traître de "pauvre con" un type qui refuse de lui serrer la main.
C'est qui qui possède le plus gros ego dans l'histoire?
Ca amuse Linus.
Si vous trainez sur la LKML, vous devez avoir vu la conversation entre Linus et Sarah Sharp, une employée de Intel qui critiquait son franc parler :
https://lkml.org/lkml/2013/7/15/374
Par contre, l'article n'est pas très clair sur le bug. Je ne suis pas sur qu'on utilise le terme renversement en Français pour le spilling. Le Spilling, c'est quand on commence à avoir trop de variables à manipuler, et qu'on vient en sauvegarder quelques une sur la pile pour libérer des registres. Le problème c'est que les accès mémoire, c'est très lent, donc moins on en fait, mieux c'est. Là, GCC 4.9 (et les précédents aussi) sauvegarde ainsi sur la pile un registre qui a une valeur constante, et le restaure après quand il en a besoin. Il est bien plus efficace d'écraser la valeur, et de la remettre plus tard avec de l'adressage immédiat (une instruction avec une valeur codée en dur dedans). Le comportement est le même, mais il n'y a pas d'accès à la pile, et c'est plus rapide.
Mais le bug n'est pas là. Ce mauvais comportement aide le bug à être révélé (le bug est présent depuis 4 ou 5 ans), mais n'est pas le vrai bug. En fait, gcc stocke les variables sur la pile, et ensuite seulement étend la taille de la pile. Si une interruption survient entre les deux, la routine d'interruption ignore qu'il y a des données à ne pas écraser au delà du pointeur de pile actuel. Pourquoi n'a-t-on pas vu le bug avant ? Parce que x86-64 prévoit une "zone rouge" de 128 octets que les routines d'interruption ne touchent pas, ce qui évite normalement de corrompre la pile dans le cas ci-dessus. Malheureusement, ici, il y a eu 136 octets de données "spilled", et donc une interruption au mauvais moment peut corrompre la stack du noyau.
Linus explique ça très bien :
https://lkml.org/lkml/2014/7/24/584
edit : en fait, ça aurait posé problème même avec le système de zone rouge, mais la zone rouge est prévue par l'ABI, pas par le processeur lui-même. En espace noyau, il ne peut donc pas y avoir de zone rouge, parce que les IT tombent dans le contexte du noyau, donc c'est encore pire.
Il est marrant lui, Linus... ben si t'es pas content, fait le toi même le compilo !
(J'aime pas les gens qui crachent sur ce qu'ils utilisent)
Le créateur de gcc c'est Richard Stallman. Là ce sont les gens qui font évoluer le truc, et parmi eux, c'est mathématique, il y a toujours des gens qui essaient d'apprendre sur le tas, et apportent des modifications qui ne sont pas forcément bonnes. Il critique je pense les gens qui manquent d'expérience et/ou/ font les choses à la va-vite genre testant à l'arrache et hop un test ça passe mon code est bon je valide même s'il est pas bon un autre corrigera, bogue suivant !
----------
Quand on passe des heures entières à s'arracher les cheveux parce qu'on sait que notre code est bon et qu'on ne comprend pas pourquoi, et qu'au bout de plusieurs heures on s'aperçoit que c'est le camarade d'à côté qui s'est penché sur une classe et, comme il débute (cf la citation de Torvalds concernant la maternelle) il a vu "en gros" qu'il faudrait faire "en gros" ça et qu'il a testé son petit cas à lui qui a résolu son "petit problème à lui tout seul" mais qui a tout pété à côté...
Je comprends qu'on soit fou de rage, car j'ai déjà vécu ça. J'aurais réagi comme ça à 25 ans... par contre aujourd'hui à mon âge je ne réagirai pas comme ça, donc je trouve qu'il est tout de même excessif. En tous les cas mettre une gifle au petit dernier qui fait n'importe quoi ça a deux conséquences possibles : il se bouge et cherche à progresser et corriger ses erreurs, ou il part.
.I..
Moi perso j'aimerai avoir des rapport de bug aussi détaillé, analysés en amont, etc...
Un rapport de bug mal analysé, avec peu de détails ne me dérange pas, si la personne n'est pas spécialiste et qu'elle reste aimable.
Un rapport de bug incendiaire mais avec toutes les infos utiles, où on sent que le mec a bien pris le temps de chercher, ne me dérange pas vraiment non plus (bon à condition que les "attaques" concernent le code, pas les personnes. Linus n'a pas explicitement insulté les personnes, mais l'outil. Ok, comme ce sont les personnes en question qui font l'outil... Ok, ok, mais la nuance existe).
Bien évidemment, tout le monde préfèrerait des rapport de bug courtois par des gens compétents qui ont pris le temps d'analyser le problème, mais on ne vit pas au pays des bisounours.
Je ne parle pas des tickets tous pourris écrits sur un ton aggressif, on sait où ils finissent
Gaïa n'est pas une marchandise.
J'ai un problème pour comprendre l'article... J'ignore totalement l'incidence que ça a de renverser des constantes, ou le renversement en général. Quelqu'un peut-il éclairer ma lanterne ?
Sinon Torvalds, je pense, joue aussi de cette image. Néanmoins, même si on peut critiquer son coté direct, il est toujours intéressant d'écouter son avis. Suffit de mettre de coté ses frasques.
C'est le genre de message qu'il a eu de Tanenbaum, le créateur de Minix. Du coup il a fait Linux.
Il est marrant lui, Linus... ben si t'es pas content, fait le toi même le compilo !
Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
Mon article sur le P2V, mon article sur le cloud
Tout d'abord j'aurais traduit "spilling" par "débordement" plutôt que par "renversement" : quand le compilateur a besoin de placer des opérandes dans les registres et qu'il n'y en a pas de libre, il déplace le contenu de ces registres vers la pile. Autrement dit on fait déborder le contenu des registres vers la pile.
Ici ce que reprochait Torvalds c'est que le compilateur faisait déborder des constantes. Ce qui est inutile : plutôt que de déplacer la constante vers la pile puis de la recharger plus tard depuis cette adresse, il aurait mieux valu n'inscrire que l'opération de chargement de la constante. Mais ce n'est qu'un problème d'optimisation, ce n'était pas le bogue lui-même.
Le véritable bogue réside dans la zone rouge. Normalement une fonction utilise deux registres de pile: rbp et rsp, qui représentent le début et la fin de la "frame" courante (l'espace disponible pour les variables de la fonction). Normalement lors de l'appel d'une sous-fonction on sauvegarde la valeur de rbp (ancien début), on remplace rbp par rsp (début = ancienne fin), puis on augmente rsp de la taille nécessaire pour les variables. Et à la fin on restaure.
Puisque tout ça est un peu lourdingue il existe un raccourci : par convention on déclare que personne n'utilisera la zone entre rsp et rsp + 128. A charge de chacun de respecter cela. Évidemment cette zone est écrasée lors d'un appel de fonction. Néanmoins cela permet bien souvent de ne pas réserver d'espace dédié sur la pile pour la fonction courante et donc de ne pas avoir à modifier rbp et rsp.
Le problème de GCC était qu'il excédait la taille de la zone rouge, écrivant dans des zones qui pouvaient ensuite être altérées par des interruptions.
Clairement Disproportionnée.
Aprés j'ai l'impression de voir dans cette guelante une petit attaque sur GNU,
je dit ca car j'ai assité a un conf de RMS est stallman nous a bien fait comprendre que torvalds et lui ne sont pas des ami et pas d'accord sur beaucoup de chose.
RMS fait du libre et torvalds de l'open-source, un désaccord éthique.
Donc c'est claire que torvalds doit se faire un plaisir de critiqué les développeurs GNU et leurs outils.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager