Discussion :

[frizou11]

Bonjour,

Dans un code existant je suis tombé sur le type unsigned __int64.
Vous avez des précisions sur ce type sachant que je suis sur une machine 32 bits ?
Par exemple si je veux afficher deux variables déclarées unsigned __int64 comme ceci :

Code :

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

1
2
3
4
5
6
unsigned __int64 var1, var2;
    var1=25;
    var2=95;
    printf("var1=%u, var2=%u\n", var1, var2);
    printf("var1=%u\n", var1);
    printf("var2=%u\n", var2);

j'obtiens :

Code :

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

1
2
3
25 0
25
95

Je ne comprends pas...

[frizou11]

Bon en fait j'ai compris il faut passer %I64u pour afficher :

Code :

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

1
2
3
4
5
6
7
 
unsigned __int64 var1, var2;
    var1=25;
    var2=95;
    printf("var1=%I64u , var2=%I64u\n", var1, var2);
    printf("var1=%I64u\n", var1);
    printf("var2=%I64u\n", var2);

Désolé pour le post qui sert à rien...

[stephl]

Le format dans le printf n'est pas correct, il correspond aux entiers utilisés par la machine, soit aux entiers 32 bits. Je crois que le format à utiliser est "%Lu".
Pour l'explication concernant l'affichage des printf, je suppose que le printf affichant les deux valeurs lit les 4 premiers octets (25 0 0 0) et affiche la valeur puis lit les 4 suivants (qui correspondent aux 4 octets de poids fort de la variable 64 bits, soit 0 0 0 0). Les 8 octets suivants correspondants aux 64 bits du deuxième entier ne sont pas lus. Bien évidemment, le problème ne se pose pas dans le cas où on utilise deux printf.

[valefor]

Si quand tu compiles ça ne geule pas c'est bizare (sous gcc essayes de passer l'option -Wall et il devrait t'expliquer des choses).

Sinon, j'ai bien une explication. Quand tu déclares %u la fonction printf s'attend à avoir un 32 bits, donc elle lit un entier de 32 bits. Donc avec un paramètre pas de problèmes. Avec deux, le deuxième lot de 32 bit contient des zéros (ha oui j'oubliai, tu doit être sur une architecture qui code les octets de poids faible en premier ?).
Ré-essaye ton test avec des chiffres plus grand que 0xffffffff ça devrait confirmer (ou infirmer cette explication).

Peut-être que la solution c'est de passer %ul ou %lu, je confond toujours...

[frizou11]

Merci pour vos réponses.
Non le compilo ne gueulait pas pourtant il est en mode parano (donc warning affichés) mais il a interprété mes valeurs comme si elles étaient codées en 32 bits. Avec %I64u ça m'affiche la bonne valeur.

Merci pour ta réponse stephl qui me fait bien comprendre ce qui se passait en affichant le zéro !

[droggo]

Jao,

Oui, avec Mingw, c'est bien %I64u qu'il faut utiliser (je me suis souvent demandé pourquoi, vu qu'il y a un standard pour faire ça !)

[Médinoc]

MinGW reste basé sur la DLL run-time de Microsoft (MSVCRT.DLL), et donc sur son implémentation non-standard de printf() etc.

La dernière version (MSVCR80.DLL) accepte le "%llu" standard (ou bien seulement "%lld") pour des entiers 64-bits. Mais toujours pas le "%zu" pour les size_t.
Et il me semble que MinGW reste basé sur la version 6, qui ne supporte pas.

PS: C'est ce que je déteste le plus chez microsoft: On dirait qu'ils font exprès de s'éloigner des standards pour leur CRT. Et il me semble qu'ils refusent C99.

[Emmanuel Delahaye]

Le format dans le printf n'est pas correct, il correspond aux entiers utilisés par la machine, soit aux entiers 32 bits. Je crois que le format à utiliser est "%Lu".

Non. Le type (unsigned __int64) n'est pas standard (Microsoft) et le formateur non plus ("%I64u").

En C99, unsigned long long est standard, et le formateur est "%llu".

Bien évidemment, le problème ne se pose pas dans le cas où on utilise deux printf.

Portnawak.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
#include <stdio.h>
 
int main (void)
{
   __int64 x = -1;
 
   printf ("%lu\n", x);
   printf ("%I64u\n", x);
 
   return 0;
}

Code :

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

1
2
3
4
5
 
4294967295
18446744073709551615
 
Press ENTER to continue.

[stephl]

Non. Le type (unsigned __int64) n'est pas standard (Microsoft) et le formateur non plus ("%I64u").

En C99, unsigned long long est standard, et le formateur est "%llu".

He, je n'ai jamais dit que c'était standard alors votre "Non" n'est pas justifié.

Portnawak.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
#include <stdio.h>
 
int main (void)
{
   __int64 x = -1;
 
   printf ("%lu\n", x);
   printf ("%I64u\n", x);
 
   return 0;
}

Code :

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

1
2
3
4
5
 
4294967295
18446744073709551615
 
Press ENTER to continue.

L'affichage est correct avec les printf() et les formats et les valeurs qui ont été utilisés (%u) au départ. C'est sûr que si vous vous amusez à modifier les formats et les valeurs que le PO a utilisé dans mon dos...

[Emmanuel Delahaye]

He, je n'ai jamais dit que c'était standard alors votre "Non" n'est pas justifié.

Comme déjà indiqué, le non portait sur ta supposition "Je crois que le format à utiliser est "%Lu"."

L'affichage est correct avec les printf() et les formats et les valeurs qui ont été utilisés (%u) au départ. C'est sûr que si vous vous amusez à modifier les formats et les valeurs que le PO a utilisé dans mon dos...

Disons qu'en tant que professionnel, je m'efforce d'écrire du code portable, dont le comportement ne dépend pas de l'utilisation...

En lisant tes différentes interventions, je pense que tu es un bricoleur moyen mais certainement pas un professionnel. Le langage C n'est pas un langage de bricoleur. Tu n'es donc pas qualifié pour répondre correctement dans un forum professionnel, d'autant plus qu'il s'adresse à des débutants qui veulent apprendre correctement le C, et pas faire de la bidouille... Pour le moment, je te conseille donc de te contenter d'écouter et d'apprendre. On a pas que ça à faire que de passer derrière des contributions approximatives ou douteuses pour rétablir la réalité.

[frizou11]

En lisant tes différentes interventions, je pense que tu es un bricoleur moyen mais certainement pas un professionnel. Le langage C n'est pas un langage de bricoleur. Tu n'es donc pas qualifié pour répondre correctement dans un forum professionnel, d'autant plus qu'il s'adresse à des débutants qui veulent apprendre correctement le C, et pas faire de la bidouille... Pour le moment, je te conseille donc de te contenter d'écouter et d'apprendre. On a pas que ça à faire que de passer derrière des contributions approximatives ou douteuses pour rétablir la réalité.

Je trouve ça un peu fort...
Pour toi si on est pas pro alors on doit se taire ?
Le principe d'un forum c'est la libre expression de chacun il me semble.
Je n'ai rien contre toi Emmanuel Delahaye mais si on s'en tient à ce que tu dis, ce forum ne vivra pas beaucoup car personne n'est parfait et tout le monde fait des erreurs, certes certains moins que d'autres. Mais le fait de répondre à certaines questions de façon approximative (parfois) et d'être repris par des pros (comme toi apparemment) permet justement de progresser.
A mon avis, se taire et écouter ne suffit pas pour progresser, il faut participer et ne pas avoir peur de dire des bêtises, et là est l'intérêt d'un forum...

PS : je rappelle que j'ai rien contre toi Emmanuel, au contraire tes interventions sont souvent très appréciées, mais parfois je trouve que tu prends certains gens, qui n'ont pas la chance d'avoir ton niveau de programmation C, d'un peu haut.

[Médinoc]

Se taire pas forcément, mais éviter de dire des c****ries oui.

Pour moi, seuls ceux qui posent les questions ont le droit de dire des c****ries, puisqu'elles font partie de la question. Une réponse erronée est bien plus dangereuse que pas de réponse du tout.
Ceux qui répondent doivent éviter de faire des erreurs, et quand on les leur signale, s'écraser et éditer leur post (et non pas protester).

[frizou11]

Se taire pas forcément, mais éviter de dire des c****ries oui.

Pour moi, seuls ceux qui posent les questions ont le droit de dire des c****ries, puisqu'elles font partie de la question. Une réponse erronée est bien plus dangereuse que pas de réponse du tout.
Ceux qui répondent doivent éviter de faire des erreurs, et quand on les leur signale, s'écraser et éditer leur post (et non pas protester).

Certes je suis d'accord avec toi. Mais quand tu ne sais pas que tu vas donner une réponse erronée, alors tu veux bien aider la personne en lui répondant.
C'est pas une fatalité de ne pas savoir qu'on sait pas.
Et je suis d'accord que lorsqu'on on est repris il ne faut pas s'énerver et essayer de comprendre pourquoi on a tort.

[stephl]

Comme déjà indiqué, le non portait sur ta supposition "Je crois que le format à utiliser est "%Lu"."
Disons qu'en tant que professionnel, je m'efforce d'écrire du code portable, dont le comportement ne dépend pas de l'utilisation...

En lisant tes différentes interventions, je pense que tu es un bricoleur moyen mais certainement pas un professionnel. Le langage C n'est pas un langage de bricoleur. Tu n'es donc pas qualifié pour répondre correctement dans un forum professionnel, d'autant plus qu'il s'adresse à des débutants qui veulent apprendre correctement le C, et pas faire de la bidouille... Pour le moment, je te conseille donc de te contenter d'écouter et d'apprendre. On a pas que ça à faire que de passer derrière des contributions approximatives ou douteuses pour rétablir la réalité.

He, ça va, vous n'avez pas trop la grosse tête? Ca vous amuse de mépriser les autres? J'ai plusieurs années d'expérience en C et sans vouloir me vanter, je pense avoir aidé pas mal de gens sur ce forum et sur d'autres, alors gardez vos remarques désobligeantes pour vous. Ce n'est pas la première fois que je vois que vous prenez les autres de haut. Je n'avais jamais rien dit jusqu'à maintenant, mais je ne vais pas me laisser insulter par vous.
Je ne "bidouille" pas et vos accusations sont mensongères. Le code que j'écris est tout à fait correct (en règle générale) et j'ai reçu plus d'un message de remerciement.

Par ailleurs, la remarque que j'avais faite sur le format dans printf était tirée de la doc Borland, c'est pour cela que j'avais écrit "je pense".