int main(void) {
float x;
x = 1.7;
return ((x + 0.1) == 1.8) ? 1 : 0;
}
j'obtiens :
$ gcc -Wall -o essai essai.c; ./essai; echo $?
0
Pourtant, le programme
#include <stdio.h>
int main(void) {
float x;
x = 1.7;
printf("%f et %f\n", 1.7 + 0.1, x + 0.1);
}
affiche :
1.800000 et 1.800000
Apparremment, 1.7+0.1 et x+0.1 sont égaux ; j'imagine qu'il s'agit d'un
problème de représentation des flottants en machine mais j'aimerais bien
avoir une confirmation ou une infirmation (et une explication, si possible).
Mais à par les Unix (incluant Mac OS X) et MS Windows, qu'y a-t-il tournant sur processeur 64 bits?
i/OS sur iSeries ? z/OS ?
Antoine
espie
In article , Jean-Marc Bourguet wrote:
Samuel DEVULDER writes:
Vincent Lefevre a écrit :
Dans l'article <4bbb7cce$0$18404$, Samuel DEVULDER écrit:
Ca veut dire quoi "sale" pour toi?
Utiliser des int implicites, par exemple.
Pourquoi? Parce que C99 l'interdit?
Je crois que tu renverses la causalité. C99 l'interdit, malgré le fait que le problème de compatibilité sont pris très au sérieux lors de la normalisation, parce que c'est quasiment universellement considéré comme une pratique non recommandable, héritage de B, langage non typé, laissés là pour faciliter le portage de programme en B et ayant survécu bien trop longtemps à son utilité.
Meme sans invoquer B, en C K&R, tu n'as pas de void, et la pratique courante pour discerner les fonctions renvoyant un int des "procedures", c'etait d'omettre le type de retour de ses dernieres (et comme sur la plupart des machines de l'epoque, l'int revenait par un registre, il n'y avait aucune difference d'ABI entre les fonctions sans valeur de retour et les fonctions renvoyantt un int). C'etait tellement cable que les premiers programmes de verification de type (lint) suivaient la meme convention (plus quelques autres du meme acabit comme le fameux /*FALLTHRU*/ des switchs)
In article <871ver65qh.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> wrote:
Samuel DEVULDER <samuel-dot-devulder@laposte-dot-com> writes:
Vincent Lefevre a écrit :
Dans l'article <4bbb7cce$0$18404$426a74cc@news.free.fr>,
Samuel DEVULDER <samuel-dot-devulder@laposte-dot-com> écrit:
Ca veut dire quoi "sale" pour toi?
Utiliser des int implicites, par exemple.
Pourquoi? Parce que C99 l'interdit?
Je crois que tu renverses la causalité. C99 l'interdit, malgré le fait que
le problème de compatibilité sont pris très au sérieux lors de la
normalisation, parce que c'est quasiment universellement considéré
comme une pratique non recommandable, héritage de B, langage non typé,
laissés là pour faciliter le portage de programme en B et ayant survécu
bien trop longtemps à son utilité.
Meme sans invoquer B, en C K&R, tu n'as pas de void, et la pratique
courante pour discerner les fonctions renvoyant un int des "procedures",
c'etait d'omettre le type de retour de ses dernieres (et comme sur la
plupart des machines de l'epoque, l'int revenait par un registre, il n'y
avait aucune difference d'ABI entre les fonctions sans valeur de retour et
les fonctions renvoyantt un int). C'etait tellement cable que les premiers
programmes de verification de type (lint) suivaient la meme convention (plus
quelques autres du meme acabit comme le fameux /*FALLTHRU*/ des switchs)
Dans l'article <4bbb7cce$0$18404$, Samuel DEVULDER écrit:
Ca veut dire quoi "sale" pour toi?
Utiliser des int implicites, par exemple.
Pourquoi? Parce que C99 l'interdit?
Je crois que tu renverses la causalité. C99 l'interdit, malgré le fait que le problème de compatibilité sont pris très au sérieux lors de la normalisation, parce que c'est quasiment universellement considéré comme une pratique non recommandable, héritage de B, langage non typé, laissés là pour faciliter le portage de programme en B et ayant survécu bien trop longtemps à son utilité.
Meme sans invoquer B, en C K&R, tu n'as pas de void, et la pratique courante pour discerner les fonctions renvoyant un int des "procedures", c'etait d'omettre le type de retour de ses dernieres (et comme sur la plupart des machines de l'epoque, l'int revenait par un registre, il n'y avait aucune difference d'ABI entre les fonctions sans valeur de retour et les fonctions renvoyantt un int). C'etait tellement cable que les premiers programmes de verification de type (lint) suivaient la meme convention (plus quelques autres du meme acabit comme le fameux /*FALLTHRU*/ des switchs)
espie
In article <hphlle$h2d$, Antoine Leca wrote:
D'un autre côté, je n'ai pas l'impression (mais je manque singulièrement de pratique) que les compilateurs C99 aient un comportement très intelligent à ce niveau : il semble que l'attitude courante est de fournir un mode C90 (avec le parseur qui accepte les int implicites) et par ailleurs un parseur C99 (qui ne les envisage pas du tout, donc renvoie des messages parfois abscons); évidemment, il est beaucoup plus compliqué d'avoir un parseur adaptatif, qui attends du C99 mais qui laisse passer des int implicites dans certains endroits sans ambiguïté, comme les déclarations ancien style, ou en présence d'un spécificateur de stockage qui précèderait (le static a=4; ci-dessus). Et quand le client se plaint, la réponse pré-écrite est « actualiser votre code » ; ce qui est le contraire des objectifs de la norme C, qui a toujours dit, « la base de code est importante, les implémentations ne le sont pas » ; en gros, les vendeurs de compilateur tiennent le haut du pavé :-(
Tres honnetement, la deprecation des implicit int, c'est anecdotique. Tout le monde a converti sans se poser de soucis. Ca a juste ete vaguement chiant a une epoque pour l'utilisateur de systemes ou les entetes systemes n'etaient pas encore converti.
Compare au superbe merdier de l'aliasing (on va faire aussi rapide que fortran, et peter trois tonnes d'ancien code de maniere extremement subtile et difficile a detecter), c'est totalement peanuts.
In article <hphlle$h2d$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:
D'un autre côté, je n'ai pas l'impression (mais je manque singulièrement
de pratique) que les compilateurs C99 aient un comportement très
intelligent à ce niveau : il semble que l'attitude courante est de
fournir un mode C90 (avec le parseur qui accepte les int implicites) et
par ailleurs un parseur C99 (qui ne les envisage pas du tout, donc
renvoie des messages parfois abscons); évidemment, il est beaucoup plus
compliqué d'avoir un parseur adaptatif, qui attends du C99 mais qui
laisse passer des int implicites dans certains endroits sans ambiguïté,
comme les déclarations ancien style, ou en présence d'un spécificateur
de stockage qui précèderait (le static a=4; ci-dessus). Et quand le
client se plaint, la réponse pré-écrite est « actualiser votre code » ;
ce qui est le contraire des objectifs de la norme C, qui a toujours dit,
« la base de code est importante, les implémentations ne le sont pas » ;
en gros, les vendeurs de compilateur tiennent le haut du pavé :-(
Tres honnetement, la deprecation des implicit int, c'est anecdotique.
Tout le monde a converti sans se poser de soucis. Ca a juste ete vaguement
chiant a une epoque pour l'utilisateur de systemes ou les entetes systemes
n'etaient pas encore converti.
Compare au superbe merdier de l'aliasing (on va faire aussi rapide que
fortran, et peter trois tonnes d'ancien code de maniere extremement subtile
et difficile a detecter), c'est totalement peanuts.
D'un autre côté, je n'ai pas l'impression (mais je manque singulièrement de pratique) que les compilateurs C99 aient un comportement très intelligent à ce niveau : il semble que l'attitude courante est de fournir un mode C90 (avec le parseur qui accepte les int implicites) et par ailleurs un parseur C99 (qui ne les envisage pas du tout, donc renvoie des messages parfois abscons); évidemment, il est beaucoup plus compliqué d'avoir un parseur adaptatif, qui attends du C99 mais qui laisse passer des int implicites dans certains endroits sans ambiguïté, comme les déclarations ancien style, ou en présence d'un spécificateur de stockage qui précèderait (le static a=4; ci-dessus). Et quand le client se plaint, la réponse pré-écrite est « actualiser votre code » ; ce qui est le contraire des objectifs de la norme C, qui a toujours dit, « la base de code est importante, les implémentations ne le sont pas » ; en gros, les vendeurs de compilateur tiennent le haut du pavé :-(
Tres honnetement, la deprecation des implicit int, c'est anecdotique. Tout le monde a converti sans se poser de soucis. Ca a juste ete vaguement chiant a une epoque pour l'utilisateur de systemes ou les entetes systemes n'etaient pas encore converti.
Compare au superbe merdier de l'aliasing (on va faire aussi rapide que fortran, et peter trois tonnes d'ancien code de maniere extremement subtile et difficile a detecter), c'est totalement peanuts.
Antoine Leca
Jean-Marc Bourguet a écrit :
J'ai plutôt tendance à considérer qu'il y a un abus de ces typedefs "de portabilité" (et d'autres définis par les bibliothèques), [...]
+1. Au niveau de Freetype on a un système de ce genre, et je ne trouve vraiment pas que ce soit terrible (même si cela s'est bien amélioré para rapport à la situation de 1998-99).
Malheureusement on veux aussi être compatible C90, et aussi que le code soit lisible... et à la fin, ce système quoique boiteux, remplit les objectifs.
Antoine
Jean-Marc Bourguet a écrit :
J'ai plutôt tendance à considérer qu'il y a un abus de ces typedefs "de
portabilité" (et d'autres définis par les bibliothèques), [...]
+1. Au niveau de Freetype on a un système de ce genre, et je ne trouve
vraiment pas que ce soit terrible (même si cela s'est bien amélioré para
rapport à la situation de 1998-99).
Malheureusement on veux aussi être compatible C90, et aussi que le code
soit lisible... et à la fin, ce système quoique boiteux, remplit les
objectifs.
J'ai plutôt tendance à considérer qu'il y a un abus de ces typedefs "de portabilité" (et d'autres définis par les bibliothèques), [...]
+1. Au niveau de Freetype on a un système de ce genre, et je ne trouve vraiment pas que ce soit terrible (même si cela s'est bien amélioré para rapport à la situation de 1998-99).
Malheureusement on veux aussi être compatible C90, et aussi que le code soit lisible... et à la fin, ce système quoique boiteux, remplit les objectifs.
Antoine
Antoine Leca
Samuel DEVULDER écrivit : [ Code de tcc ]
/** cut ../.. */ /* long is never used as type */ if ((t & VT_BTYPE) == VT_LONG) #ifndef TCC_TARGET_X86_64 t = (t & ~VT_BTYPE) | VT_INT; #else t = (t & ~VT_BTYPE) | VT_LLONG; #endif type->t = t;
Ce morceau de code me rappelle irrésistiblement un morceau de code d'il y a longtemps, qui faisait exactement pareil mais avec d'autres types : le type qui n'existait pas s'appelait int, le ifdef était pour PDP11 et IBMPC, et les promus étaient SHORT et... LONG !
Et ce bout de code a eu la vie dure, vers 1998 on avait encore des bons programmeurs C qui croyaient durs comme fer qu'en C il ne pouvait y avoir que trois types entiers (char, short et int=long), et qu'on était donc obligé d'avoir long long en plus pour traiter les 64 bits, sinon il n'y aurait plus eu de 32 bits (ou 16, en passant short=int à 32)...
ce qu'il se passe, dans cette partie c'est on remplace "long" par un int ou long long (64bits). Pour la target X86_64
Seule cible avec des 64 bits natifs supportée par tcc pour le moment.
(linux),
Euh non. ELF, plutôt. Et oui, cela exclut Win64, qui a une définition différente des conventions de passages de registres, qui ne sont pas à ma connaissance supportées par tcc pour le moment.
c'est 64bits et *partout* ailleurs (dos, arm, C67, cil) c'est du 32bits.
DOS en 64 bits, c'est positivement impossible.
Antoine
Samuel DEVULDER écrivit :
[ Code de tcc ]
/** cut ../.. */
/* long is never used as type */
if ((t & VT_BTYPE) == VT_LONG)
#ifndef TCC_TARGET_X86_64
t = (t & ~VT_BTYPE) | VT_INT;
#else
t = (t & ~VT_BTYPE) | VT_LLONG;
#endif
type->t = t;
Ce morceau de code me rappelle irrésistiblement un morceau de code d'il
y a longtemps, qui faisait exactement pareil mais avec d'autres types :
le type qui n'existait pas s'appelait int, le ifdef était pour PDP11 et
IBMPC, et les promus étaient SHORT et... LONG !
Et ce bout de code a eu la vie dure, vers 1998 on avait encore des bons
programmeurs C qui croyaient durs comme fer qu'en C il ne pouvait y
avoir que trois types entiers (char, short et int=long), et qu'on était
donc obligé d'avoir long long en plus pour traiter les 64 bits, sinon il
n'y aurait plus eu de 32 bits (ou 16, en passant short=int à 32)...
ce qu'il se passe, dans cette partie c'est on remplace "long" par un int
ou long long (64bits). Pour la target X86_64
Seule cible avec des 64 bits natifs supportée par tcc pour le moment.
(linux),
Euh non. ELF, plutôt. Et oui, cela exclut Win64, qui a une définition
différente des conventions de passages de registres, qui ne sont pas à
ma connaissance supportées par tcc pour le moment.
c'est 64bits et *partout* ailleurs (dos, arm, C67, cil) c'est du 32bits.
/** cut ../.. */ /* long is never used as type */ if ((t & VT_BTYPE) == VT_LONG) #ifndef TCC_TARGET_X86_64 t = (t & ~VT_BTYPE) | VT_INT; #else t = (t & ~VT_BTYPE) | VT_LLONG; #endif type->t = t;
Ce morceau de code me rappelle irrésistiblement un morceau de code d'il y a longtemps, qui faisait exactement pareil mais avec d'autres types : le type qui n'existait pas s'appelait int, le ifdef était pour PDP11 et IBMPC, et les promus étaient SHORT et... LONG !
Et ce bout de code a eu la vie dure, vers 1998 on avait encore des bons programmeurs C qui croyaient durs comme fer qu'en C il ne pouvait y avoir que trois types entiers (char, short et int=long), et qu'on était donc obligé d'avoir long long en plus pour traiter les 64 bits, sinon il n'y aurait plus eu de 32 bits (ou 16, en passant short=int à 32)...
ce qu'il se passe, dans cette partie c'est on remplace "long" par un int ou long long (64bits). Pour la target X86_64
Seule cible avec des 64 bits natifs supportée par tcc pour le moment.
(linux),
Euh non. ELF, plutôt. Et oui, cela exclut Win64, qui a une définition différente des conventions de passages de registres, qui ne sont pas à ma connaissance supportées par tcc pour le moment.
c'est 64bits et *partout* ailleurs (dos, arm, C67, cil) c'est du 32bits.
DOS en 64 bits, c'est positivement impossible.
Antoine
espie
In article , Jean-Marc Bourguet wrote:
J'ai plutôt tendance à considérer qu'il y a un abus de ces typedefs "de portabilité" (et d'autres définis par les bibliothèques), utilisés de manière inconstante, en supposant souvent qu'ils sont identiques quand rien ne l'impose. En pratique ils n'apportent souvent rien d'autre qu'une incitation à sous-estimer le travail nécessaire pour faire fonctionner l'application sur la cible ("il n'y a qu'à changer les typedefs").
Quand j'enseigne le C, je deconseille totalement l'utilisation de typedef sauf des cas parfaitement definis (en gros, typedef pour les types de pointeur de fonction, parce que sinon c'est vraiment imbitable).
En pre C99, typedef est "utile", mais j'ai suffisamment rame avec du code qui essayait d'integrer plusieurs bibals qui redefinissaient leur bool, uint8_t et assimile pour savoir que c'est un immonde bordel.
Les chausse-trappes de typedef sont multiples: - un typedef est global (en C++ pas ce souci: typedef est parfaitement utilisable en C++). Tout typedef dans un fichier d'entetes va tot ou tard foutre le bordel. - un typedef donne une illusion de type safety. Ca n'est qu'une equivalence, pas un nouveau type. - il est difficile de lire un code rempli de typedef sans avoir le contexte sous la main. Ca rend l'audit de code bien plus complexe.
Par exemple, si je suis sous Unix, je peux tres bien ecrire: pid_t fd = open("/etc/passwd", O_RDONLY); et mon compilo ne bronchera pas...
Les types du systeme sont utiles, et doivent etre connus.
Le seul cas ou je cautionne typedef, c'est pour emuler stdint.h sur un systeme qui n'en dispose pas (et seulement parce que les typedefs en question sont connus, documentes, et relativement sans surprise).
Meme les divers comites se sont fait avoir par typedef, a mon avis. L'utilisation de types non signes tels que size_t, l'absence de ssize_t dans la norme du C, ou encore le bazar qui traine autour de ptrdiff_t tendraient a prouver qu'il vaut souvent mieux faire encore plus simple, si on veut que ca marche...
In article <877hoj66e6.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> wrote:
J'ai plutôt tendance à considérer qu'il y a un abus de ces typedefs "de
portabilité" (et d'autres définis par les bibliothèques), utilisés de
manière inconstante, en supposant souvent qu'ils sont identiques quand rien
ne l'impose. En pratique ils n'apportent souvent rien d'autre qu'une
incitation à sous-estimer le travail nécessaire pour faire fonctionner
l'application sur la cible ("il n'y a qu'à changer les typedefs").
Quand j'enseigne le C, je deconseille totalement l'utilisation de typedef
sauf des cas parfaitement definis (en gros, typedef pour les types de
pointeur de fonction, parce que sinon c'est vraiment imbitable).
En pre C99, typedef est "utile", mais j'ai suffisamment rame avec du code
qui essayait d'integrer plusieurs bibals qui redefinissaient leur bool, uint8_t
et assimile pour savoir que c'est un immonde bordel.
Les chausse-trappes de typedef sont multiples:
- un typedef est global (en C++ pas ce souci: typedef est parfaitement
utilisable en C++). Tout typedef dans un fichier d'entetes va tot ou tard
foutre le bordel.
- un typedef donne une illusion de type safety. Ca n'est qu'une equivalence,
pas un nouveau type.
- il est difficile de lire un code rempli de typedef sans avoir le contexte
sous la main. Ca rend l'audit de code bien plus complexe.
Par exemple, si je suis sous Unix, je peux tres bien ecrire:
pid_t fd = open("/etc/passwd", O_RDONLY);
et mon compilo ne bronchera pas...
Les types du systeme sont utiles, et doivent etre connus.
Le seul cas ou je cautionne typedef, c'est pour emuler stdint.h sur un
systeme qui n'en dispose pas (et seulement parce que les typedefs en question
sont connus, documentes, et relativement sans surprise).
Meme les divers comites se sont fait avoir par typedef, a mon avis.
L'utilisation de types non signes tels que size_t, l'absence de ssize_t
dans la norme du C, ou encore le bazar qui traine autour de ptrdiff_t
tendraient a prouver qu'il vaut souvent mieux faire encore plus simple,
si on veut que ca marche...
J'ai plutôt tendance à considérer qu'il y a un abus de ces typedefs "de portabilité" (et d'autres définis par les bibliothèques), utilisés de manière inconstante, en supposant souvent qu'ils sont identiques quand rien ne l'impose. En pratique ils n'apportent souvent rien d'autre qu'une incitation à sous-estimer le travail nécessaire pour faire fonctionner l'application sur la cible ("il n'y a qu'à changer les typedefs").
Quand j'enseigne le C, je deconseille totalement l'utilisation de typedef sauf des cas parfaitement definis (en gros, typedef pour les types de pointeur de fonction, parce que sinon c'est vraiment imbitable).
En pre C99, typedef est "utile", mais j'ai suffisamment rame avec du code qui essayait d'integrer plusieurs bibals qui redefinissaient leur bool, uint8_t et assimile pour savoir que c'est un immonde bordel.
Les chausse-trappes de typedef sont multiples: - un typedef est global (en C++ pas ce souci: typedef est parfaitement utilisable en C++). Tout typedef dans un fichier d'entetes va tot ou tard foutre le bordel. - un typedef donne une illusion de type safety. Ca n'est qu'une equivalence, pas un nouveau type. - il est difficile de lire un code rempli de typedef sans avoir le contexte sous la main. Ca rend l'audit de code bien plus complexe.
Par exemple, si je suis sous Unix, je peux tres bien ecrire: pid_t fd = open("/etc/passwd", O_RDONLY); et mon compilo ne bronchera pas...
Les types du systeme sont utiles, et doivent etre connus.
Le seul cas ou je cautionne typedef, c'est pour emuler stdint.h sur un systeme qui n'en dispose pas (et seulement parce que les typedefs en question sont connus, documentes, et relativement sans surprise).
Meme les divers comites se sont fait avoir par typedef, a mon avis. L'utilisation de types non signes tels que size_t, l'absence de ssize_t dans la norme du C, ou encore le bazar qui traine autour de ptrdiff_t tendraient a prouver qu'il vaut souvent mieux faire encore plus simple, si on veut que ca marche...
Jean-Marc Bourguet
Samuel DEVULDER writes:
Jean-Marc Bourguet a écrit :
Samuel DEVULDER writes:
On attends tous la révision *Vincent* de la norme.
Surprise! les normes ont des défauts. Les plus graves sont corrigés (le troisième jeu de révision de C99 date de 2007, je doute qu'il y en ai un autre avant la publication de C1X), quand on s'en rend compte, que ce n'est pas trop invasif, et qu'on se met d'accord sur la correction. Mon impression est qu'ici le problème est tellement peu grave que la correction
Tu as raison.. et encore si problème il y a. Tous n'ont pas remarqués de pbs dans cette partie là de la norme. Je doute même que ca fasse ambiguïté si on avait pas tellement embrouillé les cartes dans ce fil de discussion.
Il n'y a pas ambiguité, c'est pour cela que je classe dans les changements à laisser à l'éditeur. (Le texte est clair mais n'emploie pas une expression de façon rigoureuse -- le même relachement ailleurs pourrait être ambigu).
-- Jean-Marc FAQ de fclc: http://www.levenez.com/lang/c/faq Site de usenet-fr: http://www.usenet-fr.news.eu.org
Samuel DEVULDER <samuel-dot-devulder@laposte-dot-com> writes:
Jean-Marc Bourguet a écrit :
Samuel DEVULDER <samuel-dot-devulder@laposte-dot-com> writes:
On attends tous la révision *Vincent* de la norme.
Surprise! les normes ont des défauts. Les plus graves sont corrigés (le
troisième jeu de révision de C99 date de 2007, je doute qu'il y en ai un
autre avant la publication de C1X), quand on s'en rend compte, que ce n'est
pas trop invasif, et qu'on se met d'accord sur la correction. Mon
impression est qu'ici le problème est tellement peu grave que la correction
Tu as raison.. et encore si problème il y a. Tous n'ont pas remarqués de
pbs dans cette partie là de la norme. Je doute même que ca fasse ambiguïté
si on avait pas tellement embrouillé les cartes dans ce fil de discussion.
Il n'y a pas ambiguité, c'est pour cela que je classe dans les changements
à laisser à l'éditeur. (Le texte est clair mais n'emploie pas une
expression de façon rigoureuse -- le même relachement ailleurs pourrait
être ambigu).
--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org
On attends tous la révision *Vincent* de la norme.
Surprise! les normes ont des défauts. Les plus graves sont corrigés (le troisième jeu de révision de C99 date de 2007, je doute qu'il y en ai un autre avant la publication de C1X), quand on s'en rend compte, que ce n'est pas trop invasif, et qu'on se met d'accord sur la correction. Mon impression est qu'ici le problème est tellement peu grave que la correction
Tu as raison.. et encore si problème il y a. Tous n'ont pas remarqués de pbs dans cette partie là de la norme. Je doute même que ca fasse ambiguïté si on avait pas tellement embrouillé les cartes dans ce fil de discussion.
Il n'y a pas ambiguité, c'est pour cela que je classe dans les changements à laisser à l'éditeur. (Le texte est clair mais n'emploie pas une expression de façon rigoureuse -- le même relachement ailleurs pourrait être ambigu).
-- Jean-Marc FAQ de fclc: http://www.levenez.com/lang/c/faq Site de usenet-fr: http://www.usenet-fr.news.eu.org
Samuel DEVULDER
Marc Espie a écrit :
Sam, maintenant qu'a peu pres tout le monde s'est range du cote de Vincent,
Il n'est pas question de "coté".. enfin je crois pas. Il n'est pas question d'opinion sur quoi ou qui que ce soit, mais de faits. Vincent a écrit des choses inexacte (je ne dis pas fausse, c'est pas dramatique), il nous enjoint d'aller voir la norme quand on lui demande des précisions qu'il aurait pu fournir. Et quand la dessus on lui montre que ca ne parle absolument pas de "binary exponent" pour décrire ce qui suit le 'p' du format %a, il s'enfonce un peu plus en nous sortant la doc de strtod quand on parle de printf %a. Question foutage de gueule, et mauvaise foi, c'est du lourd.
tu ne voudrais pas betement laisser tomber et "stop to argue until you're blue in the face" (desole, je vois pas comment la traduire, celle-la)
Ben si chercher la doc de printf %a dans strtod ne dérange personne, et autre bétises ou abus du genre, pourquoi pas. Mais on ne me fera pas prendre des vessies[*] pour des lanternes, car question lanterne on aura trouvé Vincent plus bien plus lumineux et utile dans d'autres discussions.
sam. ___ [*] ou V-5 (unix) ;-)
Marc Espie a écrit :
Sam, maintenant qu'a peu pres tout le monde s'est range du cote de Vincent,
Il n'est pas question de "coté".. enfin je crois pas. Il n'est pas
question d'opinion sur quoi ou qui que ce soit, mais de faits. Vincent a
écrit des choses inexacte (je ne dis pas fausse, c'est pas dramatique),
il nous enjoint d'aller voir la norme quand on lui demande des
précisions qu'il aurait pu fournir. Et quand la dessus on lui montre que
ca ne parle absolument pas de "binary exponent" pour décrire ce qui suit
le 'p' du format %a, il s'enfonce un peu plus en nous sortant la doc de
strtod quand on parle de printf %a. Question foutage de gueule, et
mauvaise foi, c'est du lourd.
tu ne voudrais pas betement laisser tomber et "stop to argue until you're
blue in the face" (desole, je vois pas comment la traduire, celle-la)
Ben si chercher la doc de printf %a dans strtod ne dérange personne, et
autre bétises ou abus du genre, pourquoi pas. Mais on ne me fera pas
prendre des vessies[*] pour des lanternes, car question lanterne on aura
trouvé Vincent plus bien plus lumineux et utile dans d'autres discussions.
Sam, maintenant qu'a peu pres tout le monde s'est range du cote de Vincent,
Il n'est pas question de "coté".. enfin je crois pas. Il n'est pas question d'opinion sur quoi ou qui que ce soit, mais de faits. Vincent a écrit des choses inexacte (je ne dis pas fausse, c'est pas dramatique), il nous enjoint d'aller voir la norme quand on lui demande des précisions qu'il aurait pu fournir. Et quand la dessus on lui montre que ca ne parle absolument pas de "binary exponent" pour décrire ce qui suit le 'p' du format %a, il s'enfonce un peu plus en nous sortant la doc de strtod quand on parle de printf %a. Question foutage de gueule, et mauvaise foi, c'est du lourd.
tu ne voudrais pas betement laisser tomber et "stop to argue until you're blue in the face" (desole, je vois pas comment la traduire, celle-la)
Ben si chercher la doc de printf %a dans strtod ne dérange personne, et autre bétises ou abus du genre, pourquoi pas. Mais on ne me fera pas prendre des vessies[*] pour des lanternes, car question lanterne on aura trouvé Vincent plus bien plus lumineux et utile dans d'autres discussions.
sam. ___ [*] ou V-5 (unix) ;-)
Jean-Marc Bourguet
Samuel DEVULDER writes:
Jean-Marc Bourguet a écrit : ----8<-----------------------
Antoine Leca a écrit :
> Il reste Microsoft qui eux sont restés sur long2 bits, tout en > expliquant qu'il ne faut pas utiliser les types de base (ni printf).
----8<-----------------------
Oui donc je re-écris: il n'y a pas que MSVC qui soit encore 32bits. Rien de plus, rien de moins.
1/ Le contexte est pour moi clair, il s'agit de cibles 64 bits. Le fait qu'une cible 32 ou 16 bits ait des long sur 32 bits n'est discutté par personne (ni même le fait que mon implémentation exotique favorite ait ses long sur 36 bits -- et encore dans le genre exotique je ne vais pas très loin, il y a toujours des machines sur Internet).
2/ Il s'agit de Microsoft Windows et pas de MSVC. A nouveau ce genre de choix est du ressort de l'ABI et de l'OS, pas de l'arbitraire du compilateur (même pour le C++ il y a des efforts de compatibilité d'ABI, pourtant celle-ci gère des choses un peu plus complexe). Les autres implémentations de C pour Windows (cf la doc du compilateur d'Intel par exemple) suivent naturellement celle de MS sur ce point comme sur d'autres.
3/ J'attends donc un OS 64 bits autre que Windows qui n'ai pas ses long sur 64 bits. Vu qu'on a déjà classé les Unix, z/OS et VMS, il va falloir tapper dans le très exotique (mon impression est que les premiers OS 64 bits -- Cray, HAL -- pour autant qu'ils avaient une implementation de C tappaient plutôt dans le ILP64 ou même le SILP64; ceux là sont donc vraisemblablement une mauvaise piste). Je suis sincèrement intéressé, j'aime bien les cas tordus -- et encore plus comprendre comment on y est arrivé.
A+
-- Jean-Marc FAQ de fclc: http://www.levenez.com/lang/c/faq Site de usenet-fr: http://www.usenet-fr.news.eu.org
Samuel DEVULDER <samuel-dot-devulder@laposte-dot-com> writes:
Jean-Marc Bourguet a écrit :
----8<-----------------------
Antoine Leca a écrit :
> Il reste Microsoft qui eux sont restés sur long2 bits, tout en
> expliquant qu'il ne faut pas utiliser les types de base (ni printf).
----8<-----------------------
Oui donc je re-écris: il n'y a pas que MSVC qui soit encore 32bits. Rien de
plus, rien de moins.
1/ Le contexte est pour moi clair, il s'agit de cibles 64 bits. Le fait
qu'une cible 32 ou 16 bits ait des long sur 32 bits n'est discutté par
personne (ni même le fait que mon implémentation exotique favorite ait ses
long sur 36 bits -- et encore dans le genre exotique je ne vais pas très
loin, il y a toujours des machines sur Internet).
2/ Il s'agit de Microsoft Windows et pas de MSVC. A nouveau ce genre de
choix est du ressort de l'ABI et de l'OS, pas de l'arbitraire du
compilateur (même pour le C++ il y a des efforts de compatibilité d'ABI,
pourtant celle-ci gère des choses un peu plus complexe). Les autres
implémentations de C pour Windows (cf la doc du compilateur d'Intel par
exemple) suivent naturellement celle de MS sur ce point comme sur d'autres.
3/ J'attends donc un OS 64 bits autre que Windows qui n'ai pas ses long sur
64 bits. Vu qu'on a déjà classé les Unix, z/OS et VMS, il va falloir
tapper dans le très exotique (mon impression est que les premiers OS 64
bits -- Cray, HAL -- pour autant qu'ils avaient une implementation de C
tappaient plutôt dans le ILP64 ou même le SILP64; ceux là sont donc
vraisemblablement une mauvaise piste). Je suis sincèrement intéressé,
j'aime bien les cas tordus -- et encore plus comprendre comment on y est
arrivé.
A+
--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet a écrit : ----8<-----------------------
Antoine Leca a écrit :
> Il reste Microsoft qui eux sont restés sur long2 bits, tout en > expliquant qu'il ne faut pas utiliser les types de base (ni printf).
----8<-----------------------
Oui donc je re-écris: il n'y a pas que MSVC qui soit encore 32bits. Rien de plus, rien de moins.
1/ Le contexte est pour moi clair, il s'agit de cibles 64 bits. Le fait qu'une cible 32 ou 16 bits ait des long sur 32 bits n'est discutté par personne (ni même le fait que mon implémentation exotique favorite ait ses long sur 36 bits -- et encore dans le genre exotique je ne vais pas très loin, il y a toujours des machines sur Internet).
2/ Il s'agit de Microsoft Windows et pas de MSVC. A nouveau ce genre de choix est du ressort de l'ABI et de l'OS, pas de l'arbitraire du compilateur (même pour le C++ il y a des efforts de compatibilité d'ABI, pourtant celle-ci gère des choses un peu plus complexe). Les autres implémentations de C pour Windows (cf la doc du compilateur d'Intel par exemple) suivent naturellement celle de MS sur ce point comme sur d'autres.
3/ J'attends donc un OS 64 bits autre que Windows qui n'ai pas ses long sur 64 bits. Vu qu'on a déjà classé les Unix, z/OS et VMS, il va falloir tapper dans le très exotique (mon impression est que les premiers OS 64 bits -- Cray, HAL -- pour autant qu'ils avaient une implementation de C tappaient plutôt dans le ILP64 ou même le SILP64; ceux là sont donc vraisemblablement une mauvaise piste). Je suis sincèrement intéressé, j'aime bien les cas tordus -- et encore plus comprendre comment on y est arrivé.
A+
-- Jean-Marc FAQ de fclc: http://www.levenez.com/lang/c/faq Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
(Marc Espie) writes:
In article <20100407075358$, De toutes facons, ca fait plus de dix ans que gcc emet des avertisssements pour les types implicites avec -Wall... Il a bien fallu nettoyer au moins les fichiers d'entetes (ceux de X11 par exemple), ne serait-ce que pour ne pas etre innonde d'avertissements inutiles a la premiere compile avec -Wall...
et inclure ces entêtes dans du code C++.
-- Jean-Marc FAQ de fclc: http://www.levenez.com/lang/c/faq Site de usenet-fr: http://www.usenet-fr.news.eu.org
espie@lain.home (Marc Espie) writes:
In article <20100407075358$2945@prunille.vinc17.org>,
De toutes facons, ca fait plus de dix ans que gcc emet des avertisssements
pour les types implicites avec -Wall... Il a bien fallu nettoyer au moins
les fichiers d'entetes (ceux de X11 par exemple), ne serait-ce que pour
ne pas etre innonde d'avertissements inutiles a la premiere compile avec
-Wall...
et inclure ces entêtes dans du code C++.
--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org
In article <20100407075358$, De toutes facons, ca fait plus de dix ans que gcc emet des avertisssements pour les types implicites avec -Wall... Il a bien fallu nettoyer au moins les fichiers d'entetes (ceux de X11 par exemple), ne serait-ce que pour ne pas etre innonde d'avertissements inutiles a la premiere compile avec -Wall...
et inclure ces entêtes dans du code C++.
-- Jean-Marc FAQ de fclc: http://www.levenez.com/lang/c/faq Site de usenet-fr: http://www.usenet-fr.news.eu.org
