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.
Uzytkownik "jerry1111" snipped-for-privacy@wp.pl napisal w wiadomosci news:db63la$n0d$ snipped-for-privacy@news.onet.pl...
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.
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
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
Marek Michalkiewicz napisał(a):
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.
U¿ytkownik "Piotr Wyderski" snipped-for-privacy@ii.uni.wroc.pl> napisa³ w wiadomo¶ci news:db6cq8$mf6$ snipped-for-privacy@news.dialog.net.pl...
Jakby siê stosowa³o zalecenia K&R to nie by³o by takich problemów ... ;)
Pozdro.!
Have something to add? Share your thoughts — no account required.
Ask the community — no account required