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
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.