affichage d'un long double

**zariski63** · 21/07/2006, 12h11

Bonjour

!

Souhaitant vérifier la fonctionnalité de ma machine et de code blocks, j'ai tapé ce programme:

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
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
 
 
int main()
{
    long double a = 6.2e26 ;
 
    printf(" Taille d'un char : %d octets \n\n",sizeof(char));
    printf(" Taille d'un int : %d octets \n\n",sizeof(int));
    printf(" Taille d'un long : %d octets \n\n",sizeof(long));
    printf(" Taille d'un long long: %d octets \n\n",sizeof(long long));
    printf(" Taille d'un float : %d octets \n\n",sizeof(float));
    printf(" Taille d'un double: %d octets \n\n",sizeof(double));
    printf(" Taille d'un long double: %d octets \n\n",sizeof(long double));
 
    printf("\n La valeur de a est : %Lg \n \n",a);
 
    system("PAUSE");
    return 0;
}

cependant, malgré que le format "long double" soit reconnu, l'affichage de "a" est incorrecte.
Auriez-vous une explication svp ?

Merci pour toute réponse judicieuse.

Une précision: je suis novice en C.

**David.Schris** · 23/07/2006, 01h27

Envoyé par zariski63

code blocks

Sous Linux ou Windows ? (j'y reviens après)

Envoyé par zariski63

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
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
 
 
int main()
{
    long double a = 6.2e26 ;
 
    printf(" Taille d'un char : %d octets \n\n",sizeof(char));
    printf(" Taille d'un int : %d octets \n\n",sizeof(int));
    printf(" Taille d'un long : %d octets \n\n",sizeof(long));
    printf(" Taille d'un long long: %d octets \n\n",sizeof(long long));
    printf(" Taille d'un float : %d octets \n\n",sizeof(float));
    printf(" Taille d'un double: %d octets \n\n",sizeof(double));
    printf(" Taille d'un long double: %d octets \n\n",sizeof(long double));
 
    printf("\n La valeur de a est : %Lg \n \n",a);
 
    system("PAUSE");
    return 0;
}

Pas de problème dans le code.

Envoyé par zariski63

Une précision: je suis novice en C.

Pas d'inquiétude, ça se soigne. Il faut juste savoir que le traitement est plus lourd avec certains qu'avec d'autres...et que peu survivent.

Bon, revenons à ton problème...

Si tu es sous Windows, (j'ai la flemme de vérifier donc) je vais te demander (enfin...à toi ou à quelque autre volontaire ayant la même configuration que toi) de vérifier quelle(s) DLL est/sont utilisée(s) par ton exécutable.
Si il est lié à msvcrt.dll et qu'il utilise le printf() de cette DLL, alors cela pourrait (<- conditionnel => hypothèse => rien de sûr => pas taper) expliquer ton problème. Jettes un oeil à Run-Time Library Reference / Size and Distance Specification
/ Size Prefixes for printf and wprintf Format-Type Specifiers : tu y vois un "L" (majuscule) ? Moi pas.

Si tu es sous Linux, donnes-nous la version de ta libc qu'on puisse comparer ailleurs avec la même version histoire d'être sûr.
Pour connaître cette version, tu fais un "ldd executable", tu repères la ligne de la libc (ex. : "libc.so.6 => /lib/i686/libc.so.6") tu fais un "file /lib/i686/libc.so.6" (en adaptant le chemin à ton cas) et si c'est un lien tu nous dis vers quoi il pointe (ex. : dans "/lib/i686/libc.so.6: symbolic link to libc-x.y.z.so", c'est la libc6 et la GlibC "x.y.z" [1]).

Voilà-voilà... Enfin, c'était juste une idée, comme ça...

[1]: avec un "G" comme "GNU" pas comme "GTK"...ne pas confondre avec la GLib...

**zariski63** · 23/07/2006, 10h35

Tout d'abord merci pour la réponse

!

Si tu es sous Windows, (j'ai la flemme de vérifier donc) je vais te demander (enfin...à toi ou à quelque autre volontaire ayant la même configuration que toi) de vérifier quelle(s) DLL est/sont utilisée(s) par ton exécutable.
Si il est lié à msvcrt.dll et qu'il utilise le printf() de cette DLL, alors cela pourrait (<- conditionnel => hypothèse => rien de sûr => pas taper) expliquer ton problème. Jettes un oeil à Run-Time Library Reference / Size and Distance Specification
/ Size Prefixes for printf and wprintf Format-Type Specifiers : tu y vois un "L" (majuscule) ? Moi pas.

Alors là pour moi c'est sportif, que dois-je faire ou quelle conclusion dois-je en tirer

?

**David.Schris** · 23/07/2006, 12h21

Envoyé par zariski63

Tout d'abord merci pour la réponse

!

Alors là pour moi c'est sportif, que dois-je faire ou quelle conclusion dois-je en tirer

?

Tu récupères PEDump chez Microsoft. L'exécutable récupéré est un installeur. Tu le lances, tu lis la licence et si tu n'as pas d'objection tu cliques sur "Yes". Tu choisis le dossier où il décompresse le tout et tu valides. Dans ce dossier tu trouveras des fichiers source et un répertoire "Debug". Dans "Debug" tu auras un binaire appelé "pedump.exe". Déplace/copie ce binaire dans le même répertoire que ton exécutable. En ligne de commande, tu te places dans ce répertoire ("cd cheminVersleRepertoire") et tu tapes "pedump nomDeTonExe.exe > dump.txt". Ensuite tu ouvres "dump.txt" et tu vas à la fin. Là, tu dois trouver quelque-chose qui ressemblera à :

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
28
29
30
31
32
33
34
35
36
37
Imports Table:
  KERNEL32.dll
  Import Lookup Table RVA:  0000XXXX
  TimeDateStamp:            00000000
  ForwarderChain:           00000000
  DLL Name RVA:             0000XXXX
  Import Address Table RVA: 0000XXXX
  Ordn  Name
     1  AddAtomA
   155  ExitProcess
   175  FindAtomA
   220  GetAtomNameA
   735  SetUnhandledExceptionFilter
 
  msvcrt.dll
  Import Lookup Table RVA:  0000XXXX
  TimeDateStamp:            00000000
  ForwarderChain:           00000000
  DLL Name RVA:             0000XXXX
  Import Address Table RVA: 0000XXXX
  Ordn  Name
    39  __getmainargs
    60  __p__environ
    62  __p__fmode
    80  __set_app_type
   121  _cexit
   233  _iob
   350  _onexit
   388  _setmode
   533  abort
   540  atexit
   560  fflush
   569  fprintf
   575  free
   626  malloc
   639  printf
   656  signal

Comme tu peux le voir, ce matin j'ai eu un peu plus de courage qu'hier et j'ai essayé ton programme sur une machine sous Windows (en le compilant avec GCC/MinGW32, donc a priori le même compilateur que toi, à part la version peut-être) :
- j'ai constaté le problème ;
- l'exécutable importe, comme je le supposais, la fonction "printf()" de "msvcrt.dll".

On peut trouver une confirmation à http://www.mingw.org/MinGWiki/index.php/C99. On y apprend que msvcrt.dll semble se conformer au C89 mais pas au C99, d'où un manque de fonctionnalités...

A http://www.mingw.org/MinGWiki/index.php/long%20double, ils proposent deux façons de faire pour contourner le problème. Vois si cela te suffit.

Un truc qui peut aider si tu t'aperçois qu'il te manque des fonctions sous Windows (ex. pris au hasard : "llrintf()") : lier ton programme avec mingwex ("libmingwex.a" dans le répertoire "lib"), une librairie fournie dans le paquet mingw-runtime (qui contient les entêtes et librairies qui décrivent l'API de MSVCRT et de mingwex).
Tant que tu y es, vérifies si tes versions de MinGW, des entêtes/librairies sont récentes. Si ce n'est pas le cas, tu peux faire une mise à jour : cela ne fait normalement pas de mal.

Enfin, il ne faut pas trop taper sur MinGW à ce sujet. A http://msdn.microsoft.com/chats/tran...io_022703.aspx on peut lire :

Envoyé par Microsoft

In general, we have seen little demand for many C99 features. Some features have more demand than others, and we will consider them in future releases provided they are compatible with C++. It is more likely we'll entertain C99 features if they are picked up in the next version of the C++ standard.

Autrement dit : Microsoft a estimé que tu n'avais pas besoin des fonctionnalités du C99. Tu peux les remercier (et doublement les remercier si tu es un scientifique qui a besoin des "long double").

Voilà... des questions ?

**zariski63** · 23/07/2006, 13h36

Alors là chapeau

!

Je n'ai pas le temps cet après-midi de travailler vos conseils mais je suis agréablement surpris par la réponse.
Je ne manquerai pas de vous faire part des résultats futurs...

Encore une fois mille merci

!

**thewho** · 23/07/2006, 17h33

Bonjour,

Ce post m'a donné envie de voir ce qui se passe, et c'est effectivement ce que dit David.Schris, avec quelques précisions:

- pour initialiser des valeurs, le même problème se pose:
si on cherche à faire

Code :

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

long double ld = 1.0eXXX

avec XXX > 308, c'est à dire la limite des double, alors l'initialisation se trompe et donne un INF.

- bien que mingw affiche

Envoyé par mingw

sizeof(long double) = 12

en pratique, les 2 octets de poids fort ne sont jamais utilisés, et sont = 0

Les 10 autres octets utilisent le format standard interne de la FPU des processeurs Intel (pour Motorola et autres, je ne sais pas), à savoir
dans l'ordre plus signifiant à moins signifiant:
- 1 bit de signe
- 15 bits pour l'exposant, avec offset = 16383 (2^14 -1)
- 1er bit de la mantisse toujours à 1 (alors que pour les autres formats de flottants, ce bit n'est jamais écrit dans la valeur, il est implicite)
- le reste pour la suite de la mantisse

Bref, je me demande pourquoi ils utilisent 12 octets, alors que 10 seulement sont utilisés.

Pour résoudre les problèmes d'affichage et d'initialisation, je ne vois qu'un moyen : écrire les routines nécessaires.
Je ne le ferais pas, car je n'utilise que très rarement des flottants, et les double, voire même souvent les float me suffisent largement.

affichage d'un long double

C

Vue hybride

Discussions similaires

Partager

Partager