Discussion :

[_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, 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.

[Thierry Chappuis]

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

[Sve@r]

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...

[Vincent Rogier]

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...)

[Médinoc]

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

[corrector]

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?).

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

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

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?

[corrector]

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.

[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).

Thierry

[Thierry Chappuis]

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

[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...

[corrector]

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 :

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.

[corrector]

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.

[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.

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

[Thierry Chappuis]

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

[_Michel]

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

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

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 ?

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?

[dapounet]

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 c :

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

1
2
3
4
5
#ifdef _MSC_VER
  typedef _int64 LONG_LONG;
#else
  typedef long long LONG_LONG;
#endif

[Thierry Chappuis]

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.

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

Ca devient rare, mais ça existe.

Thierry

[_Michel]

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.

[diogene]

_Michel :

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)