Multiplication de nombres entiers signés et non signés

Bonjour,

Soit le code suivant:

Code:

---

1 2 3 4 5 6 7

unsigned int a = 10; int b = -6; int tmp;   tmp = a * b;   printf("%d\n", tmp);

---

Cela affiche -60.
Mais il me semble que b est converti en unsigned et devient donc très grand, et que ce code fonctionne parce que mon compilateur utilise la représentation en complément à 2.
Est-ce que c'est correct ? Est-il raisonable d'assumer que la majorité des machines et compilateurs actuels utilisent cette représentation ?

Bonjour,

Citation:

---

Est-ce que c'est correct ? Est-il raisonable d'assumer que la majorité des machines et compilateurs actuels utilisent cette représentation ?

---

En soi, et en l'état actuel des choses, oui : il est extrêmement peu probable que tu travailles un jour sur une machine construite de telle manière qu'elle puisse mettre en défaut ce calcul-ci.

Citation:

---

Mais il me semble que b est converti en unsigned et devient donc très grand, et que ce code fonctionne parce que mon compilateur utilise la représentation en complément à 2.

---

C'est la section 6.3.1 de la norme (au moins dans n1256, pour C99) qui définit un comportement officiel, fût-il indéfini. Dans le cas présent, on lit :

Citation:

---

Envoyé par n1256

If an int can represent all values of the original type, the value is converted to an int;
otherwise, it is converted to an unsigned int. These are called the integer
promotions. 48) All other types are unchanged by the integer promotions.

---

et

Citation:

---

6.3.1.3 Signed and unsigned integers

1 When a value with integer type is converted to another integer type other than _Bool, if
the value can be represented by the new type, it is unchanged.
2 Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or
subtracting one more than the maximum value that can be represented in the new type
until the value is in the range of the new type. 49)
3 Otherwise, the new type is signed and the value cannot be represented in it; either the
result is implementation-defined or an implementation-defined signal is raised.

---

… ainsi que d'autres définitions pour tous les autres cas possibles mais qui peuvent se résumer à peu près ainsi :
— les promotions de types se font autant que possible vers le plus fort des deux types des opérandes d'une opération (et pas sur le premier rencontré),
— quand on fait des opérations sur des entiers, si un int (signé, donc) peut représenter la valeur, alors elle est automatiquement considérée comme telle (c'est le cas qui t'intéresse ici) ;
— si l'entier est trop grand, il est converti en unsigned en « ajoutant ou soustrayant autant de fois que nécessaire la valeur maximum représentable + 1 ». Il s'agit en fait d'assurer la congruence que l'on rencontre sur les entiers en binaire naturel (complément à 2) en formalisant ce comportement de manière officielle ;
— de guerre lasse, si rien ne fonctionne, le résultat est laissé à l'appréciation de l'implémentation cible, qui peut aussi choisir de lancer un signal à la place.

Bonjour,
STP sur quel machine travailles tu et avec quel compilo?
J'ai fait l’expérience avec mingw32 et le résultat est -60
J'ai même affiché le résulta de l'opération entre les types promus (appliquer la promotion des entier comme expliquée par Obsidian, sans passer par le int temp) est le résultat est -60

Code:

---

1 2 3

printf("%d\n", a * b);

---

Bonjour,

En dehors des problèmes de promotions, il faut remarquer que tu passes un %d comme type de champs à printf. Du coup le paramètre est interprété comme un entier signé (int).
Le code

Code:

---

1 2 3 4 5 6 7 8 9 10 11

#include <stdio.h>   int main (void) { int a=4294967236; unsigned int b=-60;   printf ("4294967236 en d -> %d\n", a); printf (" -60 en u -> %u\n", b);   return 0; }

---

donne comme sortie :

Code:

---

1 2	4294967236 en d -> -60 -60 en u -> 4294967236

---

Citation:

---

Envoyé par enclair

Mais il me semble que b est converti en unsigned et devient donc très grand

---

Bonjour

"Très grand" et "très petit" n'ont pas de sens en informatique. b contient une seule et même valeur codée (généralement) 1111 1111 1111 1010b soit 0xfffa.
Le fait que l'affichage donne -6 ou 4294967290 ne vient (comme l'a remarqué picodev) que du printf et de sa façon de représenter cette valeur.

Ceci dit, même en suivant ta logique, on retombe quand-même sur nos pattes. b même "très grand" multiplié par a (10) donnera le nombre 0xffffffc4 (étonamment plus petit mais ce qui se comprend quand on les place sur un cercle allant de 0x00 à 0xffffffff) ce qui, affiché correctement, donnera alors -60.