Discussion :

[Pragmateek]

Salut!

Ceci:

Code :

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

int n = 1;

est il équivalent à :

Code :

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

int n = 0x01;

sur toute les implémentations ?

Autrement dit est-ce que "0x01" n'est qu'une notation signifiant "le chiffre 1 en héxadécimal" et sera interprété à la compilation comme "int n = 1", ou bien est-ce que cela impose l'organisation mémoire?

Par exemple sur une implémentation où l' "int" "1" est codé sur 2 bytes ainsi:

Code :

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

11111111 11111111

est-ce que "int n = 0x01" sera stocké ainsi:

Code :

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

11111111 11111111

ou ainsi:

Code :

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

00000000 11111111

?

Merci.

[diogene]

La constante 1 ,en décimal, est du même type que la constante 0x1, en hexadécimal. Pour des valeurs (beaucoup) plus importantes de la constante, cela ne peut pas être toujours le cas et la réduction à un int peut donner des résultats différents.
La valeur obtenue est indépendante de l'endian utilisé par la mémoire et donnera dans les deux cas la valeur 1

Par exemple sur une implémentation où l' "int" "1" est codé sur 2 bytes ainsi:
11111111 11111111

Existe t-il une telle implémentation dans la norme ??

est-ce que "int n = 0x01" sera stocké ainsi:
11111111 11111111ou ainsi:
00000000 11111111

Ceci étant , le 0 et le 1 de l'écriture hexa ne représente que 4 bits, pas 8.

[Bayard]

unsigned short pemet d'indiquer clairement que la variable sera stockée sur 2 octets.

la longueur du type "unsigned int" ou "int" dépends du compilateur.

[Jean-Marc.Bourguet]

unsigned short pemet d'indiquer clairement que la variable sera stockée sur 2 octets.

la longueur du type "unsigned int" ou "int" dépends du compilateur.

La longueur de tous les types dépends du compilateur. J'ai par exemple accès à une machine où les short font 18 bits (les char 9, les int et les long 36).

[Jean-Marc.Bourguet]

La constante 1 ,en décimal, est du même type que la constante 0x1, en hexadécimal. Pour des valeurs (beaucoup) plus importantes de la constante, cela ne peut pas être toujours le cas et la réduction à un int peut donner des résultats différents.

Je ne vois pas de tel cas. Tu penses à quel cas?

[Jean-Marc.Bourguet]

Non.

• 1 est de type int
• 0x1 est de type unsigned int.

Les deux sont de type int. Un littéral supérieur à INT_MAX et inférieur à UINT_MAX sera de type unsigned int s'il est octal ou hexadécimal et de type long s'il est décimal et inférieur à LONG_MAX.

[Emmanuel Delahaye]

Les deux sont de type int. Un littéral supérieur à INT_MAX et inférieur à UINT_MAX sera de type unsigned int s'il est octal ou hexadécimal et de type long s'il est décimal et inférieur à LONG_MAX.

Ce n'est pas trop ce que j'avais conclu des discussions lues sur clc il y a quelques années, ni déduit du comportement de Borland C 3.1 (qui se trompait peut être, après tout), mais je te fais confiance.

[Jean-Marc.Bourguet]

Ce n'est pas trop ce que j'avais conclu des discussions lues sur clc il y a quelques années, ni déduit du comportement de Borland C 3.1 (qui se trompait peut être, après tout), mais je te fais confiance.

Les deux premières phrases du message 9 sont presque une traduction du texte de C90. C99 est encore plus clair: il y a un tableau a double entrée avec une colonne pour les décimaux, une colonne pour les autres, et une ligne par suffixe.

[Pragmateek]

Une implémentation où une telle combinaison de bits vaudrait 1 ne pourrait pas supporter le langage C.

D'accord, parce que la vraie question était de savoir si le test d'endianness :

Code :

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

1
2
3
4
5
6
7
8
9
int n = 1;
if(*(char*)(&n) == 0)
{
/*big endian*/
}
else
{
/*little endian*/
}

pourrait être mit en défaut sur une implémentation exotique.

[Jean-Marc.Bourguet]

Autrement dit est-ce que "0x01" n'est qu'une notation signifiant "le chiffre 1 en héxadécimal" et sera interprété à la compilation comme "int n = 1",

La manière dont les littéraux sont écrits ne change rien.

[Emmanuel Delahaye]

Ceci:

Code :

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

int n = 1;

est il équivalent à :

Code :

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

int n = 0x01;

sur toute les implémentations ?

Pour cette valeur (1), oui. La représentation textuelle est toujours traduite de la même façon, c'est à dire en binaire : 0<...>000001

Autrement dit est-ce que "0x01" n'est qu'une notation signifiant "le chiffre 1 en héxadécimal" et sera interprété à la compilation comme "int n = 1", ou bien est-ce que cela impose l'organisation mémoire?

Par exemple sur une implémentation où l' "int" "1" est codé sur 2 bytes ainsi:

Code :

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

11111111 11111111

Une implémentation où une telle combinaison de bits vaudrait 1 ne pourrait pas supporter le langage C.

est-ce que "int n = 0x01" sera stocké ainsi:

Code :

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

11111111 11111111

ou ainsi:

Code :

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

00000000 11111111

Quelque soit la constante utilisée (1, 01, 0x1, 0x00001 etc.), la valeur binaire sera toujours 0<....>000001.

Les combinaisons de bits que tu montres au-dessus valent respectivement 0xFF (255) et 0x0F (15). A noter qu'un int fait plutôt 16 bits (ou plus) que 8, soit :

Code :

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

1
2
3
 
00000000 00000000 11111111 11111111 (0x00FF)
00000000 00000000 00000000 11111111 (0x000F)

[Jean-Marc.Bourguet]

Par contre, il faut savoir qu'une constante décimale 1, 256, 32768, est de type int, ce qui peut poser un problème avec l'interprétation qui en est faite si la valeur est > INT_MAX.

Pour être portable, il est recommandé de forcer le mode 'unsigned' avec u (ou U) au dela de 32766 : 32767u. Attention aussi à ne pas dépaser INT_MAX. 1000000U n'est pas forcément défini, et il faut alors forcer en long avec l (ou L) :

1000000L, voire 10000000UL si on dépasse LONG_MAX etc. avec long long (C99)...

Par contre, les constantes 0... (octales) et 0x... (héxadécimales), sont toujours non signées, mais les même limitations s'appliques, et on a parfois recours à L ou LL (C99)

Les littéraux décimaux sans suffixe ont pour type le premier qui peut représenter la valeur dans la liste: int, long int, unsigned long int.

Les littéraux octals (octaux?) ou hexadécimaux sans suffixe ont pour type le premier qui peut représenter la valeur dans la liste: int, unsigned int, long int, unsigned long int.

Les suffixes font la chose évidente.

Modification pour C99: ajout de long long, et les constantes décimales sans suffixes ne sont jamais d'un type non signé.

Les suffixes de taille sont utiles dans deux contextes, et à chaque fois pour empécher un littéral d'être interprété comme d'un type plus petit que celui désiré:
- quand les promotions conduiraient à un mauvais type pour le résultat d'un opérateur (principalement quand les deux opérandes sont des littéraux ou pour les opérateurs assymétriques dans le traitement du type comme les décalages),
- quand le littéral est un paramètre à une fonction variadique ou dont aucun prototype n'a été vu.