-2147483648, long ou pas?

Bonjour à tous.
J'ai un petit problème dans la compilation de mon code : le compilateur m'envoie le message suivant:
projectpath\file.c(71) : warning C4146: unary minus operator applied to unsigned type, result still unsigned

Voilà la ligne de code sur lequel le warning porte :
*num = -2147483648;

Pourtant si je ne me trompe pas les "signed long int" (sur lequel num pointe) vont de -2^31 à 1^31-1, or -2147483648 = -2^31 .

Le compilateur ne devrai donc pas considerer comme un nombre non signé.
Je peut toujours feinter le compilateur en mettant "*num = -2147483647 - 1", mais je crois que feinter un compilateur n'est pas toujours la bonne solution pour pas truffer le code de bugs vicieux.

La norme assure qu'un entier de type signed long int peut prendre des valeurs entre 2**31 - 1 et -(2**31 - 1). Ton implantation, elle, assure des valeurs entre LONG_MIN et LONG_MAX (inclure limits.h).

Thierry

Citation:

---

Envoyé par _Michel

mais je crois que feinter un compilateur n'est pas toujours la bonne solution pour pas truffer le code de bugs vicieux.

---

Excellent état d'esprit. En effet, il ne faut JAMAIS feinter un compilo mais au contraire toujours essayer de piger pourquoi il râle...

Salut,

La réponse de ton problème se trouve sur MSDN (définition du warning C4146) :

Utilises INT_MIN (limits.h) au lieu de -2147483648

(Rmq : 2 clicks sur google ont fait l'affaire...)

(et pour la petite histoire, Visual utilise la feinte dans son #define de INT_MIN)

Citation:

---

Envoyé par _Michel

Bonjour à tous.
J'ai un petit problème dans la compilation de mon code : le compilateur m'envoie le message suivant:
projectpath\file.c(71) : warning C4146: unary minus operator applied to unsigned type, result still unsigned

Voilà la ligne de code sur lequel le warning porte :
*num = -2147483648;

Pourtant si je ne me trompe pas les "signed long int" (sur lequel num pointe) vont de -2^31 à 1^31-1 (sic), or -2147483648 = -2^31 .

---

Et c'est bien le problème : 2147483648 > 2^31 - 1, n'est pas représentable par un int, il a donc le type unsigned int (le C est assez vicieux).

L'opposé d'un non-signé est non-signé bien entendu.

Ton "-2147483648" vaut exactement 2147483648U (sur ton implémentation, avec long : 32 bits).

Converti en long, le résultat est -2147483648 sur la plupart des implémentations (y a t-il des exceptions parmi les implémentations qui peuvent représenter ce nombre?).

Citation:

---

Envoyé par _Michel

Le compilateur ne devrai donc pas considerer comme un nombre non signé.

---

Selon la norme C, si. (Rationnellement, non.)

Citation:

---

Envoyé par _Michel

Je peut toujours feinter le compilateur en mettant "*num = -2147483647 - 1", mais je crois que feinter un compilateur n'est pas toujours la bonne solution pour pas truffer le code de bugs vicieux.

---

"-2147483647 - 1" est la bonne solution en effet.

En quoi c'est une feinte?

Citation:

---

Envoyé par vicenzo

Utilises INT_MIN (limits.h) au lieu de -2147483648

---

Si il a besoin de la valeur de INT_MIN, oui.

Si il a besoin de la valeur -2147483648, non.

De toute manière, ce n'est pas portable d'utiliser cette valeur. En effet, selon la norme et comme dit plus haut, la norme garantit qu'un entier de type signed long int peut prendre une valeur entre -(2**31 - 1) et 2**31 - 1. Utiliser LONG_MIN a l'avantage d'être portable sur ce coup, mais la valeur -2147483648 codée en dur peut poser des problèmes, même avec -2147483647 - 1 (qui déborde si LONG_MIN vaut -2147483647, mais c'est rare, c'est vrai).

Thierry

Citation:

---

Envoyé par corrector

Si il a besoin de la valeur de INT_MIN, oui.

Si il a besoin de la valeur -2147483648, non.

---

Alors le seul moyen de pouvoir utiliser cette valeur de manière portable est d'utiliser un compilateur C99 supportant le type long long. On utilise alors la valeur: -2147483648LL. Mais bon, la dernière fois que je m'y suis intéressé, le compilateur de Microsoft ne supportait pas C99 (je ne sais pas ce qu'il en est avec la nouvelle version VC++ 2008).

Thierry

La dernière vois que j'ai regardé, VC++2005 supportait long long, bien qu'il s'asseye sur pratiquement tous les autres aspects de C99...

Citation:

---

Envoyé par Thierry Chappuis

De toute manière, ce n'est pas portable d'utiliser cette valeur. En effet, selon la norme et comme dit plus haut, la norme garantit qu'un entier de type signed long int peut prendre une valeur entre -(2**31 - 1) et 2**31 - 1. Utiliser LONG_MIN a l'avantage d'être portable sur ce coup, mais la valeur -2147483648 codée en dur peut poser des problèmes, même avec -2147483647 - 1 (qui déborde si LONG_MIN vaut -2147483647, mais c'est rare, c'est vrai).

---

En effet, ce n'est portable "que" sur les machines capables de représenter -2147483648, ce qui inclus notamment les machines en "complément à 2".

Puisqu'il utilise -2147483648, j'ai supposé qu'il avait réellement besoin de pouvoir représenter -2147483648.

Si en fait il a besoin de la valeur minimum d'un long, la solution correcte est effectivement LONG_MIN.

D'ailleurs, en relisant le message original, ça pourrait être le cas :

Citation:

---

Envoyé par _Michel

Pourtant si je ne me trompe pas les "signed long int" (sur lequel num pointe) vont de -2^31 à 1^31-1, or -2147483648 = -2^31 .

---

mais ce n'est pas absolument certain.

Citation:

---

Envoyé par Médinoc

La dernière vois que j'ai regardé, VC++2005 supportait long long, bien qu'il s'asseye sur pratiquement tous les autres aspects de C99...

---

L'invention de long long est bien antérieure à C99.

Pardon, le message de TC m'a induit en erreur.
Donc, VC++2005 s'assoit sur tout C99.
Y compris les modifs de la libc qui ne nécessitent aucun changement du compilateur.

Et le pire, c'est qu'ils préfèrent modifier le standard C plutôt que s'y accorder.

Citation:

---

Envoyé par corrector

L'invention de long long est bien antérieure à C99.

---

Dans C standard, non! Il existait certainement avant sous forme d'extension non portable.

Thierry

Citation:

---

Envoyé par limite.h

#define INT_MIN (-2147483647 - 1) /* minimum (signed) int value */

---

Hahaha, décidement ils n'on pas trouvé mieux que moi!

Citation:

---

De toute manière, ce n'est pas portable d'utiliser cette valeur. En effet, selon la norme et comme dit plus haut, la norme garantit qu'un entier de type signed long int peut prendre une valeur entre -(2**31 - 1) et 2**31 - 1.

---

Mais pourquoi la norme impose un truc qui mathématiquement n'est pas rigoureux ?

Citation:

---

En effet, ce n'est portable "que" sur les machines capables de représenter -2147483648, ce qui inclus notamment les machines en "complément à 2".

---

Ca existe les machines qui ne sont pas en complement à 2?

Citation:

---

Envoyé par Médinoc

Pardon, le message de TC m'a induit en erreur.
Donc, VC++2005 s'assoit sur tout C99.
Y compris les modifs de la libc qui ne nécessitent aucun changement du compilateur.

---

Il y a peut-être moyen de s'en tirer avec un typedef dans ce style-là :

Code:

---

1 2 3 4 5

#ifdef _MSC_VER typedef _int64 LONG_LONG; #else typedef long long LONG_LONG; #endif

---

Citation:

---

Envoyé par _Michel

Mais pourquoi la norme impose un truc qui mathématiquement n'est pas rigoureux ?

---

Qu'est-ce que tu ne trouves pas rigoureux? On sait que si on utilise des valeurs comprises entre -(2**31 - 1) et 2**31 - 1, on a aucun problème.

Citation:

---

Envoyé par _Michel

Ca existe les machines qui ne sont pas en complement à 2?

---

Ca devient rare, mais ça existe.

Thierry

Bon, bon, d'accord. C'est juste que si on réflechi pas trop (lol), on pourrai se dire qu'on travaille dans l'ensemble des nombres entiers modulo 2^32. A partir de ça les opérations comme l'addition et la soustraction avec dépassement de capacité sont tout à fait permises. Mais bon c'est sur que si à un moment il y avait des machines qui reflechissent différement, il faut avoir des normes qui marchent sur tout le monde.

_Michel :

Citation:

---

Voilà la ligne de code sur lequel le warning porte :
*num = -2147483648;

Pourtant si je ne me trompe pas les "signed long int" (sur lequel num pointe) vont de -2^31 à 1^31-1, or -2147483648 = -2^31 .

Le compilateur ne devrai donc pas considerer comme un nombre non signé.

---

Le problème vient de ce que les constantes entières littérales sont définies positives et non pas signées.
-2147483648 est considéré comme une expression qui calcule l'opposé de la constante 2147483648. Or, cette valeur n'est pas représentable.
D'où "l'artifice" (-2147483647 - 1)