Błąd parsera GCC: złe interpretowanie notacji naukowej w kodzie C?
GCC parser bug
From: jerry1111 <pleaseJERRY1111nomorespam_at_nospam_wp.pl>
Subject: GCC parser bug
Date: Thu, 14 Jul 2005 17:25:17 +0100
Znalezione na liscie lpc2000:
a co-worker found a bug in gcc parser (all gcc's I could get hands on):
Following bails out (but compiles correctly on all other compilers I could
get hands on):
int a = 0x3e+2;
gcc seems to take it as scientific notation.
--
Jerry
From: "Andy" <anokWYTNIJ_at_nospam_ceti.pl>
Subject: Re: GCC parser bug
Date: Thu, 14 Jul 2005 19:37:09 +0200
Uzytkownik "jerry1111" <pleaseJERRY1111nomorespam_at_nospam_wp.pl> napisal w wiadomosci news:db63la$n0d$1_at_nospam_news.onet.pl...
Znalezione na liscie lpc2000:
a co-worker found a bug in gcc parser (all gcc's I could get hands on):
Following bails out (but compiles correctly on all other compilers I could
get hands on):
int a = 0x3e+2;
gcc seems to take it as scientific notation.
Visual C++ lyka i kompiluje prawidlowo
a gcc (2.89) pisze "missing whitespace after number 0x3e"
a po wstawieniu spacji miedzy "0x3e" a "+" kompiluej prawidlowo
a gcc (3.3.5) pisze "invalid suffix on integer constant"
Dobrze, ze przynajmniej jakis blad zglasza bo juz myslalem, ze skompilije
po cichu.
--
Andrzej
From: Marek Michalkiewicz <spamtrap_at_nospam_amelek.gda.pl.invalid>
Subject: Re: GCC parser bug
Date: Thu, 14 Jul 2005 20:27:51 +0200 (CEST)
jerry1111 <pleaseJERRY1111nomorespam_at_nospam_wp.pl> wrote:
int a = 0x3e+2;
gcc seems to take it as scientific notation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3885
<cytat>
Strange as it may seem, the behavior is correct, and mandated by the
C Standard. 0x00E-0x00A is a single preprocessor token, of type
pp-number, and it must become a single compiler token, but it can't.
The gotcha is the `E-' sequence, that makes it seem like the exponent
notation of floating-point constants.
</cytat>
Marek
From: Wojtek Kaniewski <wojtekka_at_nospam_SPAM.SPAM.SPAM>
Subject: Re: GCC parser bug
Date: Thu, 14 Jul 2005 21:11:30 +0200
Marek Michalkiewicz napisał(a):
<cytat>
Strange as it may seem, the behavior is correct, and mandated by the
C Standard. 0x00E-0x00A is a single preprocessor token, of type
pp-number, and it must become a single compiler token, but it can't.
The gotcha is the `E-' sequence, that makes it seem like the exponent
notation of floating-point constants.
</cytat>
dziwne, bo w definicji ,,pp-number'' nie wzmianki o liczbach
heksadecymalnych -- może się składać tylko z cyfr dziesiętnych (6.4.8,
6.4.2.1). zresztą preprocesor gcc i tak tej kontrukcji nie rusza. za to
w defincji ,,floating-number'' token ,,e'' może wystąpić tylko w
przypadku liczby dziesiętnej. przy heksadecymalnej przewiduje się tylko
,,p'' dla wykładników binarnych (6.4.4.2).
chyba że mam jakiś nieaktualny opis standardu (ISO/IEC 9899:1999).
w.
From: "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl>
Subject: Re: GCC parser bug
Date: Thu, 14 Jul 2005 21:01:33 +0200
jerry1111 wrote:
int a = 0x3e+2;
gcc seems to take it as scientific notation.
To nie blad parsera, tylko definicja tokenu tej postaci w lekserze
jest zgodna ze standardem C. No to jest kolejny powód do
otaczania operatorów infiksowych spacjami... :-)
Pozdrawiam
Piotr Wyderski
From: "Grzegorz Stanczyk" <goo_at_nospam_WYTNIJ.TOmail.atr.bydgoszcz.pl>
Subject: Re: GCC parser bug
Date: Thu, 14 Jul 2005 23:32:36 +0200
Użytkownik "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl> napisał w wiadomości
news:db6cq8$mf6$1_at_nospam_news.dialog.net.pl...
jerry1111 wrote:
int a = 0x3e+2;
gcc seems to take it as scientific notation.
To nie blad parsera, tylko definicja tokenu tej postaci w lekserze
jest zgodna ze standardem C. No to jest kolejny powód do
otaczania operatorów infiksowych spacjami... :-)
Jakby się stosowało zalecenia K&R to nie było by takich problemów ... ;)
Pozdro.!
--
Grzegorz