Discussion :

[Batfly]

Bonjour,

J'ai croisé un code à tester assez bizarre dont voici l'exemple:

Code :

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

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
 
#include <stdlib.h>
#include <stdint.h>
#include <stdio.h>
#include <stdbool.h>
#include <string.h>
#include <errno.h>
 
int main()
 
 int16_t X= 0;
 bool Y= 1;
 
 X = -99;
 
    /*commandeGisement verification */
 
// if ((X > 100)) // Cas A
if ((X > 100u)) //Cas B
    {
    Y = 0;
    }
 
   printf(" l=%i\n cg = %i\n",Y, X);
 
 return 0;
}

Dans le Cas A (100, actuellement en commentaire), si X est une valeur entre -100 et -1, Y retournera 1

Dans le Cas B (100u, non commenté), si X est une valeur entre -100 et -1, Y retournera 0


Pourtant, 100u et 100 ont la même valeur, donc X restera toujours inférieur à cette valeur.

Est-ce que le compilateur, quand il rencontre le cas de figure B, met X en uint16 et non pas en int16? dans ce cas, pour le cas -99, pourquoi cela ne reste t-il pas à 1?

Quelque sait-il comment cela se déroule?

[Matt_Houston]

La valeur entière de X est en effet convertie en entier non signé avant la comparaison. IIRC la norme précise que - et ce quelque soit l'encodage sous-jacent - la conversion d'un entier négatif z doit renvoyer l'entier positif n le plus petit tel qu'il soit congru au nombre négatif modulo 2 élevé à la puissance du nombre de bits b utilisé pour représenter n. Autrement formulé, on obtient n = 2^b - |z|, ou n = 2^b + z .

Dans ton cas avec 100u de type unsigned int, on devrait avoir (UINT_MAX devant se traduire 2^32 - 1) :

Code :

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

1
2
const int16_t i = -99;
assert((unsigned int)i == UINT_MAX + i + 1);

[Batfly]

Wow! c'est assez tripan comme conversion.

Donc ma valeur convertie dans mon cas est égal à (2^32 - 1 -99 +1) (ce ne serait pas plutôt (2^16 - 1 -99 +1) , vue que je compare à un uint16?) , ce qui donne un résultat énorme pour une raison qui m'échappe encore :/ .

Merci en tout cas, ça m'éclaire sur ce point.

[Matt_Houston]

Dans le cas général, le type de 100u est unsigned int comme je l'ai précisé. Il existe probablement des plate-formes où ce type est confondu avec uint16_t mais c'est faux pour les architectures 64-bit, notamment.

[Sve@r]

Bonjour

Donc ma valeur convertie dans mon cas est égal à (2^32 - 1 -99 +1) (ce ne serait pas plutôt (2^16 - 1 -99 +1) , vue que je compare à un uint16?)

Je pense que les calculs/comparaisons se font quand-même tous en 32 bits.

Mais au lieu de comparer, pourquoi n'affiches-tu pas directement X ? Avec tous les formats possibles "%d", "%u", "%hd", "%hu", "%ld", "%lu"...

[Batfly]

En effet, les information sont beaucoup plus clair en voyant les résultat sous les autres format, suis-je bête ^^ .

mais à la base, c'était surtout pour comprendre un code un poil plus complexe qui utilisait cette condition et qui retournait (forcément) une erreur quand on insérait une valeur négative.

merci, je marque ce soucis comme résolu!