Discussion :

[moldavi]

Bonjour.

Ce que je trouve le plus insultant, c'est pas la remarque, le but du core est d'être optimisé aux petits oignons, et Linus est garant de cela,

La remarque de Linus concerne clairement la lisibilité/compréhension du morceau de code, pas l'optimisation.

D'ailleurs si l'optimisation était de mise, le code de Linus ne présenterait pas deux fois le même calcul (hlen + sizeof(struct frag_hdr). Ce sera certes une micro-optimisation, mais cela montre que ce n'est pas le but ici.

Et visiblement la sécurité du code non plus, puisque Linus dit très bien que le calcul de (hlen + sizeof(struct frag_hdr) + 8) peut aussi déborder...

[Chuck_Norris]

Qu'est ce que ce chiffre 8 ?

Même si de manière générale je suis d'accord sur les nombres magiques, ici on parle clairement de MTU, si la notion relative à ce 8 est complexe à expliquer (et donc à expliciter dans un nom de constante) et que tout le monde sait que c'est 8 et ça ne peut qu'être 8, alors autant écrire 8 plutôt que de créer une constante à 20 caractères pour définir quelque chose qui ne sera jamais autre chose que 8. A ce niveau-là je parlerai de tolérance vu que le nom de la variable auquel ce 8 est comparé permet de savoir clairement de quoi on parle. Et je préfère largement trouver "8" qu'une constante "EIGHT".

l'ordre d’évaluation

A ma connaissance le noyau est en C, et l'ordre d'évaluation (+ prioritaire à <) est commun à de nombreux langages. Je vois mal surcharger de parenthèses (et donc nuire à la lisibilité) simplement parce que certains langages exotiques (dans lequel jamais aucun module noyau ne sera écrit) ont une priorité différente.

Et sinon, autre remarque: il serait bien que Linus prennent quand même des leçons de diplomatie, autant sur le font il a raison, autant sur la forme il a loupé sa communication.

Je préfère un noyau efficace grâce au talent d'un codeur génial et grincheux plutôt qu'un noyau inefficace écrit par un codeur charismatique mais médiocre.

Toute façon, venant d'un type qui utilise "goto"... Autant le premier code ne check rien, autant celui de Torvalds est une merde infâme.

Le premier code utilisait déjà le goto pour commencer donc c'est malvenu de mettre ça sur le dos de Linus, et ensuite de nombreux ouvrages affirment que goto est toléré dans la gestion d'erreur (ce qui est le cas ici) si les gérer d'une autre manière nuit à la lisibilité globale du code ou à la performance. De plus, il n'y a pas d'exception en C, et de toute manière la gestion d'exceptions à un coût qu'on ne peut pas se permettre au niveau noyau.

A mon taf, ça passe pas la revue de code.

Chaque entreprise a ses standards de code. De plus je doute qu'on puisse comparer le développement d'un noyau au développement de logiciel lambda.

J'imagine la tête des profs qui rabâchent d'année en année à leurs étudiants que faire du goto est un sacrilège !!!

Les professeurs sont là pour enseigner de bonnes pratiques pour éviter les mauvais départs, mais les beaux principes de la fac doivent parfois s'effacer devant la réalité du terrain, et c'est bien plus souvent qu'on croit.

Dans ce cas que devrais-je dire du Pacman écrit en Java par les professeurs à l'époque où j'étais sur les bancs de l'école, où ils ont poussé les "bonnes pratiques" tellement à l'extrême (tout objet dans ce cas précis) que le jeu ramait énormément même sur les machines les plus puissantes de l'époque.

J'ai fait un test tout bête :

Je ne pense pas que la complexité de ton test soit comparable à celle d'un extrait du code noyau. Après, il est évident que les compilateurs sont de plus en plus doués pour générer du code efficace quelle que soit la structure de langage utilisée.

[rpasquier.gp]

Je ne suis pas d'accord avec Linus sur le principe.

Une fonction bien nommée comme overflow_usub() apporte du sens au test (mtu < hlen + sizeof(struct frag_hdr) + 8).
Si on doit tester plusieurs fois l' "overflow usub" dans le code Linux, dupliquer l'expression (mtu < hlen + sizeof(struct frag_hdr) + 8) me semble une mauvaise idée car si le test devait changer ( par exemple 8 devient 16), il faudrait rechercher dans le code le sens des inégalités... Aie!!!

Par contre la signature de overflow_usub() me paraît très bizarre...

[octal]

Et je préfère largement trouver "8" qu'une constante "EIGHT".

Je considère que ni l'un ni l'autre n'est une bonne pratique. un "8" magique est à banir, et définir un constant "EIGHT" pour remplacer "8" est une pratique stupide et peut être naive de la programmation. On ne donne pas un nom à une constante pour la remplacer facilement plus tard, le nom doit être explicite de ce que représente cette constante pour documenter implicitement le code.
Entre "8" ou "EIGHT" et quelque chose comme "PROCESS_HEADER_SIZE" il y a un monde quand même.

[Jipété]

Ouais !

D'autant plus que, comme l'a dit quelqu'un, si jamais elle doit changer de valeur, ça va être le bazar. Non mais, vous imaginez

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Const
  EIGHT = 16;

[N_BaH]

de ce que je peux comprendre du message de Torvalds,

The conflict I get is due to stupid new gcc header file crap.

il me semble que c'est à gcc qu'il s'en prend, et ses "particularismes", non ? Ce n'est d'ailleurs pas la première fois qu'il en a après gcc.

et, forcément, ceux qui les utilisent ne sont pas oubliés. :/

[Deneb31]

A la vitesse a laquelle evolue l AI je soupçonne que le problème fondamental est que ce genre de bricoles ne devraient pas être du domaine des hommes.

[nirgal76]

Je mettrais ma main à couper que c'est exécuté en mode kernel.

Dans ce cas là, un goto est parfaitement acceptable, ce qui ne veut pas dire qu'il faut en abuser et l'utiliser n'importe comment.
.

De toute façon, while, goto ou autre, ça finira en saut une fois compilé an asm
Je dirais que le "+8" placé magiquement me dérange beaucoup plus que le goto.