From: SourceForge.net <no...@so...> - 2006-12-20 23:16:01
|
Bugs item #982435, was opened at 2004-06-30 05:48 Message generated for change (Comment added) made by borutr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=982435&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: C Preprocessor Group: None >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Stas Sergeev (stsp) Assigned to: Borut Razem (borutr) Summary: Strange problem with preprocessor Initial Comment: Hi, Trying to compile the following: --- #define LO_B(x) ((x) & 0xff) char main() { unsigned char a=0xfe-LO_B(3); return a; } --- I get: --- wrdef.c:4: warning: function 'LO_B' implicit declaration wrdef.c:4: error: too many parameters wrdef.c:4: warning: function 'LO_B' implicit declaration wrdef.c:4: error: indirections to different types assignment from type 'void' to type 'unsigned-char' --- I don't understand what's going wrong. Looking into an sdcpp output, I can see the macro LO_B was not expanded, but I can't figure out why. Any ideas? Test-case is attached. ---------------------------------------------------------------------- >Comment By: Borut Razem (borutr) Date: 2006-12-21 00:15 Message: Logged In: YES user_id=568035 Originator: NO After looking to the current implementation in sdcpp and the "6.4.8 Preprocessing numbers" chapter in C99 standard it seems that this is not an implementation bug: the implementation follows the standard. My opinion is that this is a bug in the C99 standard, since the "identifier-nondigit" (including all letters) is treated as a part of the number (see definition of "identifier-nondigit" at "6.4.2.1 General"): the preprocessor treats "0xfe-LO_B" as a number!? I think that the preprocessor and compiler should have the same (or at least very similar) "idea" what a number is. I "fixed" the problem in revision #4520 by replacing "identifier-nondigit" with "hexadecimal-digit" and "hexadecimal-prefix" (see 6.4.4.1 Integer constants): pp-number: hexadecimal-prefix digit . digit pp-number hexadecimal-prefix pp-number digit pp-number hexadecimal-digit pp-number e sign pp-number E sign pp-number p sign pp-number P sign pp-number . I would like to hear the other opinions. We can still decide to revert the fix (or introduce a sdcpp command line switch and/or pragma)... Borut ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2006-12-20 08:25 Message: Logged In: YES user_id=568035 Originator: NO > That was actually the reason why I put it into a support > requests, not into a bugs - I also found that getting rid > of 'e' avoids the problem. I found out that if 'e' is followed by an operator different from '-' or '+', it works. This is an additional indication that 'e' is treated as an exponent delimiter. > Do you still think this is a bug? I only know that it gave > me a _lot_ of a headache, so I am inclinced to classify > it as a bug. :) By my opinion it is a bug since 0x... indicates that the number is of integral type and shouldn't accept the exponent part. > Is the sdcpp code share some parts with gcc-cpp? Just > wondering. sccpp is derivated from GCC cpp. See http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCPP+history Borut ---------------------------------------------------------------------- Comment By: Stas Sergeev (stsp) Date: 2006-12-20 06:28 Message: Logged In: YES user_id=501371 Originator: YES > I found out that the problem is only when the last character in hex > constant is 'e'. It seems that the preprocessor treats the letter 'e' as > the exponent delimiter That was actually the reason why I put it into a support requests, not into a bugs - I also found that getting rid of 'e' avoids the problem. Do you still think this is a bug? I only know that it gave me a _lot_ of a headache, so I am inclinced to classify it as a bug. :) > I'll try to fix it and post the bug/patch to GCC team. Is the sdcpp code share some parts with gcc-cpp? Just wondering. ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2006-12-19 22:10 Message: Logged In: YES user_id=568035 Originator: NO I found out that the problem is only when the last character in hex constant is 'e'. It seems that the preprocessor treats the letter 'e' as the exponent delimiter and then it gets confused... Borut ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2006-12-19 21:41 Message: Logged In: YES user_id=568035 Originator: NO I tried it with: cpp (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125), cpp (GCC) 4.1.1 20061011 (Red Hat 4.1.1-30), Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86 (VC 6.0), Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 (VC .NET 2003), Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 (VC 8.0), and the result is the same - the macro LO_B(3) is not expanded. Borland C++ Win32 Preprocessor 5.5.1 Copyright (c) 1993, 2000 Borland, Open Watcom C32 Optimizing Compiler Version 1.6 do it in the expected way - the macro LO_B(3) is expanded. I made a (very) quick search in the C standard and I didn't find anything which justifies the macro not to be expanded, so it is probably a bug. I'll try to fix it and post the bug/patch to GCC team. Borut ---------------------------------------------------------------------- Comment By: Raphael Neider (tecodev) Date: 2006-11-23 14:51 Message: Logged In: YES user_id=1115835 Originator: NO This is in fact a bug, still present in SDCC r4478: The preprocessor recognizes the definition of LO_B(x), but fails to recognize the use in 0xfe-LO_B(3) as '0xfe', '-', and 'LO_B(3)'. Inserting whitespace before the '-' as in 0xfe -LOB(3) solves this. Turned into bug report and leaving this open for the time being. Regards, Raphael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=982435&group_id=599 |