Discussion :

[Rémi Coquet]

Ce que je souligne, c'est qu'il connaît l'ambitus du résultat -> <32 bits
C'est à peu près la seule chose clairement définie.
Cela doit donc apparaître de manière explicite dans l'écriture.

Le cas "litigieux" est celui ou a<=2^32/2 -> +1073741823 / -1073741824 (puisqu'il est question d'IMUL): Une valeur max. sur 30 bits multipliée par une valeur Max <=2.
Tu reconnaîtras que c'est un cas limite ou un simple SAL 1 ou 0 est largement suffisant.

Allons plus loin, plus la résolution de "b" augmente plus celle de "a" diminue. Très rapidement, la chose qui vient à l'esprit c'est qu'il est question d'un produit de deux integer signés de taille word... -32768 * -32768.
C'est pour cela qu'il est important de le faire apparaître dans l'écriture, non seulement pour des raisons de vitesse (bien que ça ne soit pas l'important de la problématique exposée) mais surtout pour une raison de maintenance facilitée par une écriture conventionnée (coder propre sous-entend le respect de certaines règles basiques).

[youscef]

Et si l'utilisateur entre un nombre "a" qui a une taille qui dépasse un word, mais le résultat de a * b <= 32 bits ?

[Tymk]

Rémi > Heu, ce n'est pas que je sois insensible à l'application d'une méthodologie correcte, mais là je me sens un peu dépassé.

Ce que tu veux me dire, c'est que si je suis sûr d'avoir un résultat qui peut s'écrire sur 32 bits, cela signifie que mes opérandes peuvent s'écrire sur 16 bits chacune. Donc, je peux utiliser la syntaxe qui stocke le résultat dans DX:AX ?

[Rémi Coquet]

Il y a de fortes chances: Il serait plus sûr de vérifier, dans le contexte de ton application (ou exemple) l'ambitus des valeurs a et b. afin de trancher: Savoir si, effectivement, tu manipules des words ou des dwords en entrée.

@Youscef: Je pense t'avoir répondu par la même occasion.

Beaucoup de bugs sont surtout liés à la confusion LP contenu de LP mais aussi Tailleset corruptions de datas, de registres comme edx (qui sont implicites hélas). Toujours protéger les registres ebx esi edi, respecter les convention d'utilisation des divers registres (hormis à la rigueur dans de rares algos sioux quidemande à tordre les possibilités et tirer dessus au maximum). Une bonne utilisation des registre augmente la lisibilité de ton code par tout un chacun, surtout toi dans quelques mois .

Pour la méthode c'est relativemnt simple: Le code doit être le plus clair possible afin que la documentation millimètrée soit quasiment inutile.
Une fois que ton code est à ce niveau d'écriture et de lisibilité (on sait exatement que la copie de données se fait sur des char, des signed etc. que les labels possèdent des nom longs et clairs sans abréviations autres que des préfixes: LP.TABLE.MaSuiteZeroCent, STR.A.LeNomDeLaFenetre, ID.DansMaTableDeTrisHexa, LEN.STR.A.LeNomDeLaFenetreMain PATH.RepertoirePrincipale etc. à toi de fabriquer une convention stricte à laquelle tu te tiens(dras) avec rigueur) tu peux commencer à documenter de manière plus précise sur la stratégie que tu mets en oeuvre sans te perdre dans les détails qui sont maintenant explicités par le code lui même.

PS. Merci Obsidian pour les balises de code, désolé...

[youscef]

Rémi Coquet> Dès le début j'étais d'accord avec ce que tu dis, je ne t'ai jamais contrarié, puisque tu parles d'un cas général.
Mais dans ce cas, le plus logique serait d'utiliser des dword, et pas des word, car il utilise la fonction scanf("%d", &var). en C, var doit être un int (dword) et pas un short (word), donc intput1 et input2 doivent être manipulés comme des dword, et je trouve que c'est plus lisible car ça montre au lecteur du code que l'utilisateur peut entrer des dword.