bug de gcc? - Page 1

[slo@pc2 ~]$ cat bc1.c
#include <stdio.h>
int main(int argc, char **argv)
{
        printf("%X\n",0xE-2);
}

[slo@pc2 ~]$ gcc bc1.c
bc1.c:4:16: error: invalid suffix "-2" on integer constant
[slo@pc2 ~]$ cat bc2.c
#include <stdio.h>
int main(int argc, char **argv)
{
        printf("%X\n",0xE -2);
}

[slo@pc2 ~]$ gcc bc2.c
[slo@pc2 ~]$ ./a.out
C
[slo@pc2 ~]$ cat bc3.c
#include <stdio.h>
int main(int argc, char **argv)
{
        printf("%X\n",0xF-2);
}

[slo@pc2 ~]$ gcc bc3.c
[slo@pc2 ~]$ ./a.out
D
[slo@pc2 ~]$

pourquoi 0xE-2 n'est pas légal?

Sans espace, ça marche ?
'tain je vais leur apprendre à faire un parseur d'expression, moa

sans espace ça marche pour 0xF mais pas pour 0xE, sans doute a cause du parsing éventuel de 1.4E-5 pour les flottants.

Oui ça doit être ça. Ce qui veut dire que soit 0x est un nombre valide pour GCC (...) soit il considère à la foix 0xE et (int = 0)*10^-2.
Dans les deux cas ça me parait un bug mais faudrait voir ce que dit la spec du langage. (Je pourrais aussi tester avec Visual C++ si j'avais pas la flemme mais non)

en fait non, a priori c'est pas un bug mais ça a à voir avec les 'preprocessing tokens' de gcc. E serait considéré comme un truc spécial.

mais visual studio accepte les 3 syntaxes.

Ce n'est pas un bogue, c'est conforme au standard C. Le E- est parsé comme un exponentiel, donc fait partie du "preprocessing number". Ensuite, ce nombre est validé et GCC voit que 0x ne colle pas avec cette notation exponentielle, d'où l'erreur.

Les versions actuelles de GCC sont très pointilleuses sur ces histoires de tokens du préprocesseur et n'acceptent pas ce qu'elles ne sont pas obligées d'accepter. Ils disent que c'est pour rendre le préprocesseur plus efficace.

Bah, c'est comme d'ab, une erreur logique avec un message d'erreur tout ce qu'il y a de plus clair, comme GCC sais si bien le faire

Les entiers écrits en hexa (0xFF) sont traduits en entiers décimaux (255) par le preprocesseur ? Le compilateur ne voit jamais de code hexa ?
Bon Ben j'ai appris un truc sympa aujourd'hui. Mais pourquoi c'est le PP qui convertit ?

t'as pas compris.

le preproc ne transforme pas les hexa en decimaux, mais a une manière particulière de les lire.

Décimal, hexadécimal, le compilo s'en fout. Pour lui, c'est un nombre, c'est tout. Le terme de "base" n'existe que quand on convertit ce nombre en chaîne de caractères.

Non, mais le problème, c'est qu'il a à l'esprit le modèle obsolète du préprocesseur qui prend un fichier texte et en ressort un autre, qui est ensuite lexé et parsé par le compilateur à vrai dire. Mais dans les compilateurs C/C++ modernes, le lexeur est dans le préprocesseur, qui fournit directement des tokens au compilateur, le compilateur ne va pas s'amuser à relexer le tout.

merci de m'avoir désobselété alors

C'est Thibaut l'obsolète.

Ou le mec qui laisse depuis 3 ans un compilateur en version bêta sans aucune mise à jour.

C-C-C-C-COMBOOOOOO !!!!!!!!!
topics/126395-nanniv-tigcc#0