probleme déclaration constante #define

Version imprimable

17/01/2012, 08h38
boboss123

probleme déclaration constante #define
Bonjour

J'ai déclaré une constante comme ceci :

Code:

#define MA_CONSTANTE 0xFF

Le problème est que j'ai le message d'alerte suivant :

Citation:

comparison is always false due to limited range of data type

Pour le code suivant :
Code:

1 2 3 4 5 6 7 8 9 10 11 signed char maVariable; // variable 8 bits // ... // ... if(maVariable == MA_CONSTANTE){ } else { }
Comment faire pour ne pas avoir ce message (j'aimerais pour utiliser MA_CONSTANTE aussi avec des variables de type unsigned char) ?

Merci d'avance,

-------------------

j'ai le même problème si je fais ça :
Code:

1 2 3 4 #define MA_CONSTANTE '\xff' // ou #define MA_CONSTANTE 0b11111111
17/01/2012, 08h41
Bousk

Bonjour,

un char est codé sur 1 octet, soit 8 bits.
Le tien est en plus signé, donc 1 bit est celui de signe
Le range de valeurs d'un signed char est donc -128:127
0xFF vaut lui 255

donc

Citation:

comparison is always false due to limited range of data type

qu'il suffit de traduire mot-à-mot pour comprendre.
17/01/2012, 08h57
boboss123

J'avais bien compris le problème, mais il n'y a pas moyen de définir la constante en 'binaire' et que ça fonctionne avec un signed char et un unsigned char ?
17/01/2012, 10h15
Bousk
Code:

1 2 3 4 type | valeur min | valeur max signed char | -128 | 127 unsigned char | 0 | 255
Ton test représente

Code:

si (un nombre dont la valeur est toujours comprise entre -128 et 127 inclus est égal à 255)

... donc tu as un warning.

Quelle constante veux-tu définir ? quel test veux-tu réaliser ?
En tous cas celui-ci est totalement inutile et illogique, puisque toujours faux.

Tu peux représenter ce que tu souhaites et réaliser les opérations de ton choix, tant qu'elles sont logiques et réfléchies.
D'ailleurs pourquoi parler d'unsigned char alors que tu as un signed char. Soit tu énonces mal ton problèmes, soit tu oublies la moitié de celui-ci.
17/01/2012, 13h40
Bktero

Tu cherches une constante que tu pourras comparer à une variable de n'importe quel type ou tu souhaites savoir si une variable a atteint la valeur maximale qu'elle peut contenir ?

Si c'est le cas 1, je pense que c'est mort (en tout cas avec quelque chose d'aussi simple) ; si c'est le cas 2, tourne toi vers les constantes définissant les limites de chaque type.

Ben en fait c'est pour traiter des chaines de caractères

Dans un projet j'avais l'habitude de toujours utiliser des "unsigned char" pour traiter mes chaines (peut être à tord ?) et donc mes #define fonctionnaient bien.

Or depuis que j'ai mis à jours mon compilo, il me met des warning comme quoi les chaine de caractères doivent être des nombre signés (pourquoi ? ... ça je sais pas ... je ne vois pas pourquoi un caractère devrait avoir une notion de signé)

Ce que je voulais faire, c'est changer tous les unsigned char de chaine en signed char en modifiant au minimum le programme pour limiter le risque de bug.

Pour le moment, la seule solution que j'ai trouvé, c'est de faire :
Code:

1 2 3 4 #define MA_CARACTERE ((signed char)0xFF) // valeur d'un caractère spécial // => ecrire -1 est tout sauf intuitif pour savoir à quel caractère ça correspond // Est-ce que c'est valide au moins ?

18/01/2012, 11h11
Kirilenko

Attention, signed char, unsigned char et char sont trois types différents.

Pour représenter une chaîne de caractère, il faut utiliser uniquement le type char (à la rigueur, TCHAR ou wchar_t).

Les char signés et non signés indiqués explicitement ne sont censés servir qu'à représenter des nombres qui peuvent appartenir à une plage de valeur (souvent peu importante).
19/01/2012, 07h49
boboss123

j'ai défini mes chaines de caratère avec des char mais j'ai toujours une erreur sur le #define car ça sous entend que c'est une variable de type signée

Code:

#define MON_CARACTERE ((char)0xFF) // valeur d'un caractère spécial

=> c'est correcte (selon le compilateur utilisé, char peut être signé ou non) ?
19/01/2012, 10h02
Bktero

J'allais dire "pour moi, char = signed char et sont donc du même type ; unsigned char est un autre type". Puis, je me suis dit qu'il faut toujours tourné sa langue 7 fois dans sa bouche avant de parler.

Je suis donc aller voir la FAQ de Developpez (et oui...) et j'ai trouvé cette entrée : Quelle est la différence entre char, signed char et unsigned char ?. En utilisant Eclipse sous Windows (et donc gcc visiblement), l'instruction suivante m'affiche -1 :

Code:

printf("maVariable3 = %d\n",(char)255);

Pas bête le compilateur 8-)

Je pense que Kirilenko a raison quand il dit

Citation:

[1]Pour représenter une chaîne de caractère, il faut utiliser uniquement le type char

[2]Les char signés et non signés indiqués explicitement ne sont censés servir qu'à représenter des nombres

[1] surtout quand on voit par exemple le prototype de strcpy où ce sont bien des char* qui sont utilisés.

[2] est-ce que ça un intérêt sur un PC avec une RAM importante ? Ca doit surtout servir quand la RAM est très faible (un µC par exemple ? ^^)
19/01/2012, 11h43
souviron34

Citation:

Envoyé par Bktero

[2] est-ce que ça un intérêt sur un PC avec une RAM importante ? Ca doit surtout servir quand la RAM est très faible (un µC par exemple ? ^^)

pas du tout. Comme on l'a dit, pour représenter des nombres.. en binaire..

Par exemple, pour inclure une image (gif ou jpeg par exemple) à l'intérieur d'un message et l'envoyer sur un pipe ou un socket, il est bon d'avoir un buffer de unsigned char...

En utilisant les bons casts, puisqque la plupart des fonctions de type "send" prennent soit un void* soit un char *

Admettons que tu veuilles fabriquer un message du stype "DATA IMAGE = .<image>...", un peu comme une balise html sauf que tu mettrais l'image dedans..

Quand tu voudras écrire "DATA IMAGE = ", tu utiliseras des fonctions prenant des char* en entrée et/ou sortie (sprintf, etc). Par contre, lorsque tu voudras y inclure l'image, tu auras besoin des unsigned char.

Tu déclareras donc ton buffer en unsigned char Tu feras des print de texte en castant en char*, puis des memcpy sur les unsigned char..(en particulier parce que tu peux avoir des zéros (0), et que tu ne veux pas qu'ils soient pris pour des NULL, qui termineraient la chaîne)

Et tu l'enverras soit tel quel si la routine d'envoi prend des void* ou des unsigned char*, soit en castant si la routine d'envoi prend des char*.

A retenir donc : si je dois formatter un message texte contenant du binaire, je dois utilser des unsigned char pour ne pas interpréter un zéro comme une fin de chaîne (bien entendu il faut avoir un caractère de fin de la partie binaire, ou inclure dedans une longueur)
19/01/2012, 14h33
boboss123
J'ai un doute, si j'ai :
Code:

1 2 3 4 5 unsigned char uval = 255; signed char val; val = (signed char)uval;
=> val vaudra 0xFF quelque soit le compilateur utilisé ?
Code:

1 2 3 4 5 unsigned char uval; signed char val = -1; uval = (unsigned char)val;
=> uval vaudra 0xFF quelque soit le compilateur utilisé ?
19/01/2012, 15h03
Bktero
Le signed ou le unsigned t'indiquent comme lire / interpréter les 8 bits. Y a t-il ou non un bit de signe ? Je pense que ce n'est pas dépendant du compilateur mais du mode de codage des nombres sur ta machine.
- 0xFF = 0b11111111 = 255 si on est en non signé avec représentation binaire simple.
- 0xFF = 0b11111111 = -1 si on est en signé avec une représentation en complément à 2.
- 0xFF = 0b11111111 = -127 si on est en signé avec une représentation en "signe+amplitude".
Si ta machine utilise du complément à 2 (ce qui doit être le cas de tous les ordinateurs non ?), la réponse me semble clairement être "oui".

@souviron34 : il est vrai que je réfléchissais dans le cas de la déclaration du variable simple (genre int a=1 contre char a=1) et je ne pensais pas à des cas tordus de mixage de données ou lors d'envoi réseau pour limiter la quantité de données ! Merci pour les remarques !
19/01/2012, 19h42
diogene
Citation:
Envoyé par boboss123

J'ai un doute, si j'ai :

Code:

1 2 3 4 5 unsigned char uval = 255; signed char val; val = (signed char)uval;

=> val vaudra 0xFF quelque soit le compilateur utilisé ?

Code:

1 2 3 4 5 unsigned char uval; signed char val = -1; uval = (unsigned char)val;

=> uval vaudra 0xFF quelque soit le compilateur utilisé ?
Que dit la norme (n1256) :

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.

ce n'est pas le cas dans les deux exemples

Citation:

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)

C'est l'exemple 2 : uval vaut 256-1 = 255 = 0xFF (avec des char de 8 bits de données)

Citation:

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.

C'est le cas 1
20/01/2012, 15h19
boboss123

ok, merci pour l'info

donc pour la section 3, tu fais comment pour être sur d'avoir la bonne valeur quelque soit le compilo ?

rebonjour,

J'ai une autre question :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 unsigned char uVal = 252; signed char sVal = -4; // les deux variables ont la même valeur binaire // ne fonctionne pas if(uVal == sVal ){ // .. } // fonctionne if(uVal == (unsigned char)sVal ){ // .. }
=> pourquoi la comparaison n'est vrai que pour le second cas ? ... dans le premier cas, sVal ne derait-il pas être implicitement converti en unsigned char ?

01/02/2012, 19h30
diogene

Non, il y a pour les opérandes entières d'un type "plus petit" que int une promotion de type : si les valeurs de ce type sont représentables par un int, alors la valeur est promue en int sinon elle est promue en unsigned int.

uVal == sVal
uval est unsigned char 252. Après promotion, la valeur devient int 252
sVal est signed char -4. Après promotion, la valeur devient int -4
et 252 != -4

uVal == (unsigned char)sVal
uval est unsigned char 252. Après promotion, la valeur devient int 252
sVal est signed char -4
(unsigned char)sVal est unsigned char (256-4) = unsigned char 252
Après promotion, la valeur devient int 252
et 252 == 252
01/02/2012, 22h18
anacharsis

salut !

j'en ai bavé aussi. mais finalement le draft C99 :

Citation:

...
les cas non entiers ...
the integer promotions are performed on both operands. Then the following rules are applied to the promoted operands:
If both operands have the same type, then

no further conversion is needed.
Otherwise, if both operands have signed integer types or both have unsigned integer types,

the operand with the type of lesser integer conversion rank is converted to the type of the operand with greater rank.
Otherwise, if the operand that has unsigned integer type has rank greater or equal to the rank of the type of the other operand, then

the operand with signed integer type is converted to the type of the operand with unsigned integer type.
Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, then

the operand with unsigned integer type is converted to the type of the operand with signed integer type.
Otherwise,
both operands are converted to the unsigned integer type corresponding to the type of the operand with signed integer type.

c'est un peu lourd, mais,

les char, signed char, unsigned char ont le même rang,
les int, signed int, unsigned int ont même rang,
les types char ont un rang inferieur à celui des types int.

j'avais commencé ce post avant le repas, mais entre temps diogene a aussi posté. ça va dans le même sens ...

A+

Merci, je commence à mieux comprendre comment tout cela fonctionne ... c'est pas simple à interpréter la norme :)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 signed char varsc = 0xFA; switch(varsc){ // ce test est ignoré car vaut toujours false case 0xFA: // cette valeur est typée sur un int printf("test OK\r\n"); break; // ce test est pris en compte case '\xFA': // cette valeur est typée sur un char printf("test OK2\r\n"); break; // déclenche un warning comme quoi c'est identique à "case '\xFA'" case ((int)0xFFFFFFFA): // le cast (int) ne sert a rien car la valeur est par défaut de type int printf("test OK3\r\n"); break; // déclenche un warning comme quoi c'est identique à "case '\xFA'" case ((signed char)0xFA): printf("test OK4\r\n"); break; default : printf("erreur de cast\r\n"); }
=> ça confirme bien tout vos dire ;)
La constante '\xFA' est forcement de type char ou ça dépend du compilateur utilisé (avec mon compilo c'est le cas) ? ... je n'ai pas trouvé la réponse dans la doc de mon compilateur

par contre pour ce code :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 signed char varsc = 0xFA; switch(varsc){ // ce test est ignoré car vaut toujours false case 0xFA: // cette valeur est typée sur un int printf("test OK\r\n"); break; default : printf("erreur de cast\r\n"); } // le test renvoi toujours false mais ne génère pas d'erreur à la compilation if (varsc == 0xFA){ printf("test OK\r\n"); } else { printf("erreur de cast\r\n"); }
Pourquoi pour le case, le compilateur m'affiche un warning mais pas pour le if ? ça ne serait pas un bug du compilateur (c'est super dangereux) ? Vous avez le même comportement du compilo chez vous ?

Aussi, le code suivant ne devrait-il pas généré un warning car le changement de type dans ce cas est dépendant de l'implémentation du compilo ?
Code:

1 2 3 4 5 unsigned char toto = 0xFA; signed char tutu = toto; printf("%c%c\r\n", toto, tutu); // sur mon compilo, tutu à la meme valeur binaire que toto

02/02/2012, 11h47
diogene

Citation:

Code:

case '\xFA': // cette valeur est typée sur un char

Non, c'est un int.

Citation:

Code:

case ((int)0xFFFFFFFA): // le cast (int) ne sert a rien car la valeur est par défaut de type int

Non, c'est un unsigned int

Citation:

Pourquoi pour le case, le compilateur m'affiche un warning mais pas pour le if ? ça ne serait pas un bug du compilateur (c'est super dangereux) ? Vous avez le même comportement du compilo chez vous ?

Ca dépend du compilateur et des options de warning. Pour celui que j'ai essayé, il me dit "Constante hors limite dans la comparaison"

Quelques explications :

0xFA est un int (la valeur est représentable sur un int. Sinon, ce serait un unsigned int) valeur : 250
(signed char)0xFA : résultat dépendant de l'implémentation. probablement -6
varsc est signed char : résultat dépendant de l'implémentation. probablement -6

Les constantes entières caractères ont le type int. la valeur est celle d'un type char convertie en int
'\xFA' : Si char correspond à un signed char, sa valeur est -6 sinon si char est un unsigned char 250

0xFFFFFFFA est un unsigned int ayant pour valeur 2^32-6
(int)0xFFFFFFFA : résultat dépendant de l'implémentation. probablement -6

Merci encore pour tes réponses c'est très instructif (surtout que peu de cours de langage C approfondissent le sujet) :ccool:

Citation:

Envoyé par diogene

Non, c'est un int.

C'est compliqué tout ça :aie:
=> pourquoi ils ont créé le suffix 'u' si les constantes sont déjà en unsigned ?

Donc pour résumer, on a bien ça ?
Code:

1 2 3 4 5 6 7 8 0b101 // unisgned int (valeur binaire) 0x12 // unsigned int (valeur hexadecimale) 2 // unsigned int ? (valeur decimale) -2 // int ? (valeur decimale) 02 // unsigned int ? (valeur octal) '\xFA' // int (valeur hexadecimale) // ... j'en ai oublié ??
=> c'est pareil un int et un signed int ?
=> c'est possible que le type char soit de signe différent que le type int ?

Citation:

Envoyé par diogene

Ca dépend du compilateur et des options de warning. Pour celui que j'ai essayé, il me dit "Constante hors limite dans la comparaison"

J'ai le même message d'erreur mais pour les switch/case uniquement. ça ne te semble pas aberrant qu'il n'apparaisse pas pour le if (ça m'étonnerait qu'il existe une option pour activer le warning juste sur le if :aie: ) ?

Est-ce que c'est bien comme ça que ça se passe ?
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 // **************************************** signed char varsc = 0xFA; // => 0xFA est un 'unsigned int' qui vaut 0x000000FA // => varsc = (signed char)((unsigned int)0x000000FA) = -6 (dépend de l'implémentation => valeur binaire = 'FA'h) // le test renvoi toujours false mais ne génère pas d'erreur à la compilation // 1- vu que varsc est un '(signed) char', il est converti en 'int' => valTmpInt = -6 (valeur binaire = 'FFFFFFFA'h) // 2- vu que la valeur intermédaire valTmpInt est de type 'int' et que 0xFA est de type 'unsigned int', valTmpInt est converti en 'unsigned int' // => valTmpUsignedInt = (unsigned int)valTmpInt = (unsigned int)-6 = (unsigned int)'FFFFFFFA'h = 0xFFFFFFFA = 4 294 967 290 // => la conversion ne dépend pas de l'implémentation, c'est défini // 3- la comparaison se fait entre valTmpUsignedInt et 0x000000FA if (varsc == 0xFA){ printf("test OK\r\n"); } else { printf("erreur de cast\r\n"); } // **************************************** unsigned char varuc = 0xFA; // => 0xFA est un 'unsigned int' qui vaut 0x000000FA // => varuc = (unsigned char)((unsigned int)0x000000FA) = 250 // le test fonctione => vaut true // 1- vu que varsc est un '(unsigned) char', il est converti en 'int' => valTmpInt = 250 (valeur binaire = '000000FA'h) // 2- la comparaison se fait entre valTmpInt et '\xFA' sans besoin de modifier le type vu qu'ils sont tous les deux de type int if (varuc == '\xFA'){ printf("test OK\r\n"); } else { printf("erreur de cast\r\n"); } // Pour résumer : // - Le premier test ne peut fonctionner que si varsc est positif, sinon le test renvera forcement false // - Le second test est plus rapide à executer car il y a une conversion en moins à faire

02/02/2012, 16h20
diogene

Citation:

=> pourquoi ils ont créé le suffix 'u' si les constantes sont déjà en unsigned ?

Elles ne le sont pas toujours

Citation:

0b101 // unisgned int (valeur binaire)

Les constantes binaires ne sont pas dans la norme. En tant qu'extension, il est probable qu'elles suivent toujours les règles des constantes octales ou hexadécimales.

Citation:

0x12 // unsigned int (valeur hexadecimale)
02 // unsigned int ? (valeur octal)

Non, si les valeurs sont représentables par un int, elles ont le type int, sinon unsigned int , sinon long, sinon unsigned long,...

Citation:

2 // unsigned int ? (valeur decimale)
-2 // int ? (valeur decimale)

Elles sont de type int si elles sont représentables par un int sinon long, sinon long long (donc toujours d'un type signé)

'

Citation:

\xFA' // int (valeur hexadecimale)

Oui, mais la valeur dépend si char est signé ou non.

Citation:

=> c'est pareil un int et un signed int ?

oui

Citation:

=> c'est possible que le type char soit de signe différent que le type int ?

oui. C'est d'ailleurs souvent une option de compilation.
02/02/2012, 16h34
Jean-Marc.Bourguet
Citation:

Envoyé par boboss123

=> pourquoi ils ont créé le suffix 'u' si les constantes sont déjà en unsigned ?

C'est pas le cas.
Citation:
Donc pour résumer, on a bien ça ?

Code:

1 2 0b101 // unisgned int (valeur binaire)
C'est pas du C, c'est une extension parfois presente. A priori ca devrait etre int si on a suivi la logique des autres constantes.

Citation:

0x12 // unsigned int (valeur hexadecimale)

La valeur est representable dans un int donc c'est un int.

Citation:

2 // unsigned int ? (valeur decimale)

La valeur est representable dans un int donc c'est un int.

Citation:

-2 // int ? (valeur decimale)

C'est pas une constante, c'est une expression de type int.

Citation:

02 // unsigned int ? (valeur octal)

La valeur est representable dans un int donc c'est un int.

Citation:

'\xFA' // int (valeur hexadecimale)

int. De valeur -6 ou 250 suivant le fait que char soit signe ou pas.

Note que les regles pour le type des constantes ont change entre C90 et C99, mais tu ne donne pas un exemple ou elles donnent des resultats differents.

A chaque fois c'est le premier type qui permet de representer exactement la valeur dans

C90:
Sans prefixe: int, long, unsigned long
Avec prefixe: int, unsigned, long, unsigned long

C99:
Sans prefixe: int, long, long long
Avec prefixe: int, unsigned, long, unsigned long, long long, unsigned long long

Un suffixe U ne permet que les unsigned (et on utilise la liste avec prefixe meme s'il n'y en a pas)
Un suffixe L ou LL commence dans la liste a long ou long long.

merci pour vos explications (je m'étais encore trompé dans mon raisonnement :) )

Pour le changement de type entre des char/int j'ai fait quelque test pour voir comment fonctionne ce qui dépend de l'implémentation :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
 
	signed char varsc;
	unsigned char varsc;
	int iVal; // int est signed int, c'est pareil
	unsigned int uiVal;
 
 
	varsc = -6;
	varuc = varsc;
	printf("signed char(-6) -> unsigned char: %u\r\n", varuc);
 
	varsc = varuc;
	printf("unsigned char(250) -> signed char: %i\r\n", varsc);
 
	// ****
	iVal = varsc;
	uiVal = varsc;
	printf("signed char(-6) -> int: %i\r\n", iVal);
	printf("signed char(-6) -> unsigned int: %u\r\n", uiVal);
 
	// ****
	iVal = varuc;
	uiVal = varuc;
	printf("unsigned char(250) -> int: %i\r\n", iVal);
	printf("unsigned char(250) -> unsigned int: %u\r\n", uiVal);
 
	// ****
	printf("int(250) -> unsigned char: %u\r\n", (unsigned char)iVal);
	printf("int(250) -> signed char: %i\r\n", (signed char)iVal);
 
	// ****
	printf("unsigned int(250) -> unsigned char: %u\r\n", (unsigned char)uiVal);
	printf("unsigned int(250) -> signed char: %i\r\n", (signed char)uiVal);
 
	// ****
	printf("\r\n");
 
	iVal = -6;
	uiVal = iVal;
	printf("int(-6) -> unsigned int: %u\r\n", uiVal);
 
	varsc = iVal;
	varuc = iVal;	
	printf("int(-6) -> signed char: %i\r\n", varsc);
	printf("int(-6) -> unsigned char: %u\r\n", varuc);	
 
	varsc = uiVal;
	varuc = uiVal;	
	printf("unsigned int(4294967290) -> signed char: %i\r\n", varsc);
	printf("unsigned int(4294967290) -> unsigned char: %u\r\n", varuc);		
 
 
	// ****
	printf("\r\n");
 
	iVal = -4660; // = 0xFFFF00F6u
 
	uiVal = iVal;
	printf("int(-4660) -> unsigned int: %u\r\n", uiVal);
 
	varsc = iVal;
	varuc = iVal;	
	printf("int(-4660) -> signed char: %i\r\n", varsc);
	printf("int(-4660) -> unsigned char: %u\r\n", varuc);

voici ce que ça m'affiche (j'ai rajouté à la main les commentaires) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
signed char(-6) -> unsigned char: 250 // valeur binaire identique ('FA'h -> 'FA'h)
unsigned char(250) -> signed char: -6 // valeur binaire identique ('FA'h -> 'FA'h)
signed char(-6) -> int: -6 // valeur numérique identique ('FA'h -> 'FFFFFFFA'h)
signed char(-6) -> unsigned int: 4294967290 // même valeur binaire que lorsqu'on cast en int ('FA'h -> 'FFFFFFFA'h)
unsigned char(250) -> int: 250 // valeur numérique identique ('FA'h -> '000000FA'h)
unsigned char(250) -> unsigned int: 250 // valeur numérique identique ('FA'h -> '000000FA'h)
int(250) -> unsigned char: 250 // valeur numérique identique ('000000FA'h -> 'FA'h)
int(250) -> signed char: -6 // même valeur binaire que lorsqu'on cast en unsigned char ('000000FA'h -> 'FA'h)
unsigned int(250) -> unsigned char: 250 // valeur numérique identique ('000000FA'h -> 'FA'h)
unsigned int(250) -> signed char: -6 // même valeur binaire que lorsqu'on cast en unsigned char ('000000FA'h -> 'FA'h)
 
 
int(-6) -> unsigned int: 4294967290 // valeur binaire identique ('FFFFFFFA'h -> 'FFFFFFFA'h)
int(-6) -> signed char: -6 // valeur numérique identique ('FFFFFFFA'h -> 'FA'h)
int(-6) -> unsigned char: 250 // même valeur binaire que lorsqu'on cast en signed char ('FFFFFFFA'h -> 'FA'h)
unsigned int(4294967290) -> signed char: -6 // même résultat que si on cast un int qui à la même valeur binaire ('FFFFFFFA'h -> 'FA'h)
unsigned int(4294967290) -> unsigned char: 250// même résultat que si on cast un int qui à la même valeur binaire ('FFFFFFFA'h -> 'FA'h)
 
 
int(-4660) -> unsigned int: 4294962636 // valeur binaire identique ('FFFF EDCC'h) -> 'FFFF EDCC'h)
int(-4660) -> signed char: -52 // correspond à l'octet de poid faible de la valeur binaire (0xCC = -52) ('FFFF EDCC'h) -> 'CC'h)
int(-4660) -> unsigned char: 204 // correspond à l'octet de poid faible de la valeur binaire (0xCC = 204) ('FFFF EDCC'h) -> 'CC'h)

Donc en suivant les 4 règles suivantes, je peux facilement prévoir la valeur que j'aurais lors d'un changement de type, non ? Je me suis pas trompé cette fois :) ?

Citation:

- caster 'signed char' vers 'unsigned char' (où l'inverse), ne change pas la représentation binaire de la variable (mais change représentation numérique)
- caster 'signed int vers unsigned int' (où l'inverse), ne change pas la représentation binaire de la variable (mais change représentation numérique)
- caster '(signed/unsigned) char' vers '(signed/unsigned) int', ne change pas la valeur numérique de la variable (mais change la représentation binaire)
- caster '(signed/unsigned) int' vers '(signed/unsigned) char', correspond juste à récupérer l'octet de poid faible sans faire aucune modification sur celui-ci (ex : 'FFFFFFFA'h => 'FA'h)

03/02/2012, 12h19
diogene

Il faut noter que si les unsigned sont toujours codés en binaire pur, les signed ne le sont pas toujours en complément à 2 (en fait, il y a trois codages admis : complément à 2, complément à 1 et signe+valeur absolue).

La norme adopte alors une forme plus abstraite pour couvrir ces situations et ne parle pas de la transformation des représentations en binaire lors de ces changements de type mais du changement de la valeur (qui est ce qui importe au programmeur) :

Je résume :

- Si la valeur peut être représentée dans le type de destination, elle est inchangée

- Sinon, si le type de destination est unsigned, la valeur est ramenée dans la plage de validité du type de destination en ajoutant ou en soustrayant le nombre de fois qu'il faut la valeur maximum du type de destination +1

- Sinon, le résultat dépend de l'implémentation (valeur incodable dans un type de destination signed)
03/02/2012, 12h56
boboss123

Oui je l'avais bien compris.

Les 4 règles que j'ai citées ne sont à utiliser que pour le compilateur que j'utilise.

le terme "résultat dépend de l'implémentation" désigne quoi exactement ? la méthode utilisé pour le traitement du signe (complément a 2...) ou ça dépend exclusivement des spécificités du compilateur ?
03/02/2012, 13h58
diogene

Ca veut dire que le compilateur fait quelque chose de précis, à son choix, qui normalement devrait être mentionné et décrit dans sa documentation, mais que tous les compilateurs ne sont pas contraints à faire la même chose.
03/02/2012, 14h58
boboss123

oki, merci :)