int et unsigned int

Florent G wrote:

Bonjour,
voila je comprends pas. unsigned int utilise bien 4 octets pour stocker un
int et insigned int sur ma machine pourtant avec ce code la :

int main()
{
unsigned int nombre;

/*nombre = 0xffffffdd;
printf("%dn", sizeof(unsigned int));
printf("%d %xn", nombre, nombre);
*/
nombre = 4294967261;
printf("%dn",sizeof(int));
printf("%d %xn", nombre, nombre);
}

j'obtiens toujours -35 et ffffffdd.. pourquoi ca ?



C'est la directive du printf qui dit comment interpréter la valeur qu'il

trouve. %d correspond à un entier signé quant à %x il n'y a pas de
notion de signe. Mais je pense que je n ai pas compris la question...

Seb.

Bonjour,
voila je comprends pas. unsigned int utilise bien 4 octets pour stocker un
int et insigned int sur ma machine pourtant avec ce code la :

int main()
{
unsigned int nombre;

/*nombre = 0xffffffdd;
printf("%dn", sizeof(unsigned int));
printf("%d %xn", nombre, nombre);
*/
nombre = 4294967261;
printf("%dn",sizeof(int));
printf("%d %xn", nombre, nombre);
}

j'obtiens toujours -35 et ffffffdd.. pourquoi ca ?

printf recoit plusieurs parametres : le premier est un char *, et les autres...
il les traduit en fonction du format.
le %d lui dit qu'il attend un int : il traduit donc les 4 multiplets contenant
ffffffdd en int -> -35

Pour lui dire qu'il s'agit d'un unsigned int, utilises %u :
printf("%d %x %un", nombre, nombre, nombre);
donne bien :
-35 ffffffdd 4294967261

Florent G a émis l'idée suivante :

voila je comprends pas. unsigned int utilise bien 4 octets pour stocker un
int et insigned int sur ma machine pourtant avec ce code la :

Mais ce n'est pas portable. Il faut utiliser long ou unsigned long.

int main()
{
unsigned int nombre;

nombre = 4294967261;
printf("%dn",sizeof(int));
printf("%d %xn", nombre, nombre);

D'autre part, il faut être cohérent entre les types et les formateurs:

"%d" : int
"%u : unsigned int
"%x : unsigned int

"%ld" : long int
"%lu : unsigned long int
"%lx : unsigned long int

}

j'obtiens toujours -35 et ffffffdd.. pourquoi ca ?

Mauvais choix de formateurs.

--


Emmanuel

"Florent G" <gkompot@yahoo.nospam.com> a écrit dans le message de news:
cdj4o2$ef9$1@news-

unsigned int nombre;
nombre = 4294967261;

tu n'as pas le droit de faire ça meme si ça
marche sur ta machine...

un unsigned int doit etre entre 0 et 65535 ...

Le Tue, 20 Jul 2004 20:22:20 +0200, Stephane Legras-Decussy a écrit :

tu n'as pas le droit de faire ça meme si ça
marche sur ta machine...

un unsigned int doit etre entre 0 et 65535 ...

hein ????
Si c'est le cas avec ton compilateur, alors il est antédiluvien, pour ne
donner que 16 bits à un unsigned int !!!

Il me semble que la définition des types en C était plutôt du genre :
char => un octet
short int => au moins aussi grand qu'un char
int => au moins aussi grand qu'un short int

Ce qui fait qu'en théorie, tous les types peuvent être sur 8 bits, mais
en pratique sur PC (de nos jours) on a plutôt :
char => 8 bits
short int => 16 bits
int => 32 bits

Et ceci aussi bien en signed (par défaut) que unsigned.

--
Florent "flure" C.
Décrypter l'@ pour répondre
Coders don't die, they just JMP without RET !

Florent 'flure' C. vient de nous annoncer :

tu n'as pas le droit de faire ça meme si ça
marche sur ta machine...

un unsigned int doit etre entre 0 et 65535 ...

hein ????
Si c'est le cas avec ton compilateur, alors il est antédiluvien, pour ne
donner que 16 bits à un unsigned int !!!

La norme est comme ça, c'est tout. Et oui, mon compilateur (Borland C
3.1 de 1991) est ancien mais conforme à C90. Et oui, ses int font
16-bits.

#define INT_MAX 0x7FFF
#define INT_MIN ((int)0x8000)
#define UINT_MAX 0xFFFFU


Idem avec le très récent 'Code Composer 2.0' (2003) de Texas Instrument
pour DSP TMS32C54 :

#define INT_MAX 32767 /* MAX VALUE FOR INT
*/
#define INT_MIN (-INT_MAX-1) /* MIN VALUE FOR INT
*/
#define UINT_MAX 65535u /* MAX VALUE FOR UNSIGNED INT
*/

Ce n'est pas un problème de compilateur, mais de cible.

Il me semble que la définition des types en C était plutôt du genre :
char => un octet

Oui.

short int => au moins aussi grand qu'un char

Non. la gamme minimale d'un unsigned short est 0-65535

int => au moins aussi grand qu'un short int

Oui, avec la définition ci-dessus.

Ce qui fait qu'en théorie, tous les types peuvent être sur 8 bits, mais

Non.

en pratique sur PC (de nos jours) on a plutôt :
char => 8 bits
short int => 16 bits
int => 32 bits

Peut être, mais il n'y a pas que des PC. Et si tu parles du x86 Intel,
en mode réel, on a

unsigned char : 0-255
unsigned short: 0-65535
unsigned int : 0-65535
unsigned long : 0-4294967295

et en mode 386 étendu, on a

unsigned char : 0-255
unsigned short: 0-65535
unsigned int : 0-4294967295
unsigned long : 0-4294967295

Quand au TMS320C54, on a

unsigned char : 0-65535
unsigned short: 0-65535
unsigned int : 0-65535
unsigned long : 0-4294967295

bref, la vie n'est pas si simple que tu ne l'imagines.

--


Emmanuel

"Florent 'flure' C." <flurePASDESPAM@freePASDESPAM.fr> a écrit dans le
message de news: pan.2004.07.20.20.46.16.146929@freePASDESPAM.fr...

hein ????
Si c'est le cas avec ton compilateur, alors il est antédiluvien, pour ne
donner que 16 bits à un unsigned int !!!

le C dit que un int fait au moins 16 bits, et un long au moins 32bits...

Il me semble que la définition des types en C était plutôt du genre :
char => un octet

non, un byte, c'est pas pareil...

Ce qui fait qu'en théorie, tous les types peuvent être sur 8 bits, mais

euh...c'est tres chelou ton truc là...

Stephane Legras-Decussy avait soumis l'idée :

Il me semble que la définition des types en C était plutôt du genre :
char => un octet

non, un byte, c'est pas pareil...

Si. Un char et un byte ont exactement la même représentation en C. De
même, il est correct (bien que simpliste) d'écrire

"char => un octet"

Ce qui fait qu'en théorie, tous les types peuvent être sur 8 bits, mais

euh...c'est tres chelou ton truc là...

Non, c'est carrément faux!

--


Emmanuel

"Florent G" <gkompot@yahoo.nospam.com> a écrit dans le message de news:
cdj4o2$ef9$1@news-

unsigned int nombre;
nombre = 4294967261;

tu n'as pas le droit de faire ça meme si ça
marche sur ta machine...

un unsigned int doit etre entre 0 et 65535 ...

Non, un unsigned int a une valeur entre 0 et UINT_MAX. La valeur
d'UINT_MAX est défini par l'implémentation, mais doit valoir au moins 65535.
Si 4294967261 ne tient pas dans unsigned int, on sait qu'il tient au
moins dans unsigned long, et qu'il peut être convertit en unsigned int
par soustraction successives de UINT_MAX s'il est trop grand. Donc même
dans le cas où UINT_MAX vaut 65535, on a encore le droit d'écrire:

nombre = 4294967261;

Le résultat n'est pas portable, mais il est bien défini.

--
Richard

"Stephane Legras-Decussy" <pas de mail @ pas de mail> wrote:

"Florent G" <gkompot@yahoo.nospam.com> a écrit dans le message de news:
cdj4o2$ef9$1@news-

unsigned int nombre;
nombre = 4294967261;

tu n'as pas le droit de faire ça meme si ça
marche sur ta machine...

Si sur le compilateur de *sa* machine documente que le maximum d'un
unsigned int est 2^32-1 ou plus il a le droit de faire ca sur sa
machine...

un unsigned int doit etre entre 0 et 65535 ...

Un unsigned int doit etre entre 0 et 65535 quand le programme est
destiné à être compilé par un compilateur quelconque conforme a la
norme. C'est correct. Donc ce programme n'est pas "strictement
conforme à la norme" mais seulement "conforme à la norme".


--
Horst