Discussion:Somme de contrôle BSD

Bug

Un bug s'est glissé dans le code en C, qui a conduit à une correction erronée du code Java : normalement le calcul doit être fait sur des entiers non signés. Ça ne pose pas de problème si le type utilisé pour le checksum est plus long que 16 bits (le checksum est alors toujours positif ou nul). Mais avec un checksum entier signé de 16 bits, le décalage à droite est un décalage arithmétique (le bit de signe est conservé), et le checksum en début de boucle peut-être négatif ; si c'est le cas le résultat est incorrect. Les compilateurs pour machines 16 bits (par exemple pour MS-DOS et assimilé) ont habituellement un int de 16 bits, et le code ne fonctionnera pas. Le problème est le même en Java, dont tous les entiers sont signés : la version sur un octet doit donc utiliser un décalage logique.

7zz (discuter) 17 mars 2019 à 11:29 (CET)

En réalité ça n'a aucune importance en Java. Les calculs sont faits sur des entiers de 32 bits, même si toutes les variables en jeu sont de type 'byte'. En effet la JVM n'a pas d'opérations arithmétiques de 8 ou 16 bits, seulement 32 et 64, et les variables de plus petites longueurs sont converties automatiquement (avec conservation du signe). Conséquence : le shift, qu'il soit arithmétique ou logique, opère sur un entier potentiellement signé de 32 bits. Il faut donc tronquer à 8 bits avant le shift, suite à quoi le nombre est positif (on est en 32 bits et tous les bits au-delà du bit 7 sont à zéro), donc peu import que le shift soit arithmétique ou logique. De même, le "& 0x1" est inutile car les bits de poids supérieur seront détruits lors de la conversion forcée en 'byte'. 185.24.187.196 (discuter) 9 août 2019 à 12:17 (CEST)