topic Re: Question about #define in CodeWarrior for MCU

Question about #define

nfxs — Thu, 29 Oct 2020 09:41:35 GMT

Hi
Just another dumb question:

I am using Codewarrior 6.2 Release, build 8127, and targeting a HC908AP32.

If I try to compile the folowing code i get a "C2801: ')' missing" error, pointing at the line "if (x + MAX_BUFFER_LENGTH)" in the foo() function.

Code:

#include <hidef.h> /* for EnableInterrupts macro */#include "derivative.h" /* include peripheral declarations */void MCU_init(void); /* Device initialization function declaration */#define MAX_BUFFER_LENGTH 10;unsigned char x;void foo(void){  if (x + MAX_BUFFER_LENGTH)  {    x++; // do something  }}void main(void) {  MCU_init(); /* call Device Initialization */  foo();  for(;;)   {    } }

My original code was a little different and I lost some time until i realized that the semicolon at the end of the line:

define MAX_BUFFER_LENGTH 10;<---

was the problem.

My question is, if the compiler is working correctly or is it supposed to warn that there is a misplaced semicolon? Just wondering because i lost almost 30 minutes until i found the error.
Thanks in advance
Regards
Felix

Message Edited by nfxs on 2008-10-01 02:45 AM

Message Edited by nfxs on 2008-10-01 02:46 AM

Re: Question about #define

Stephen — Wed, 01 Oct 2008 13:30:51 GMT

Hi Felix
IMHO the compiler is right. The #define statement just defines the parameter as whatever you put after it - it could be a value, or a calculation or a function call or piece of text - and that is just substituted into the code when you use that parameter.

In this case you told it that MAX_BUFFER_LENGTH was "10;"
So the line became:
if (x + MAX_BUFFER_LENGTH
i.e. semi colon in the wrong place = missing closing bracket ")"

You could have put:
#define MAX_BUFFER_LENGTH (5 * 2)
this would have worked, the compiler would have done the maths and put the answer (10) into the if statement.

Hope that all makes sense. You can do some really complicated things with #defines - but my personal experience is that it's best to keep it simple. :smileyhappy:

Good luck with your programming
Steve

Re: Question about #define

Lundin — Wed, 01 Oct 2008 13:31:00 GMT

Welcome the the wonderful world of macro debugging. The compiler is working correctly, try compiling this code:

if (x + 10

I bet you get the very same error.

Painful debugging is just one of the almost countless number of reasons why one should avoid the pre-processor as far as possible.

Use constants instead of #defines, write real functions instead of function-like macros etc etc.

Message Edited by Lundin on 2008-10-01 08:31 AM

Re: Question about #define

Stephen — Wed, 01 Oct 2008 13:33:33 GMT

Nice one Freescale!
In my above reply, anywhere there is a graphic of a winking face, it should have the text semi-colon closing-bracket like "; )" - otherwise it won't make sense. Sorry about that!
Steve

Re: Question about #define

CompilerGuru — Wed, 01 Oct 2008 13:57:09 GMT

The compiler is right, the question is more if the compiler could warn if the user does unintentionally
add a semicolon to the end of a macro (or miscounts the number of closing braces, or does any of the other countless many errors you can do with macros).
The problem is that semicolons are legal, and there are real usages where macros must end with a semicolon. I don't see any reasonable way of detecting this case without also causing wrong warnings, warnings for code for which the semicolon was intentional :smileysad:.

I did actually never see any compiler issue a warning for such a added semicolon, in the end, C has a number of traps, for some the compiler can warn and for others the compiler cannot.

Daniel

Re: Question about #define

scopuli — Wed, 01 Oct 2008 19:51:56 GMT

In both C and C++ macros are simple string substitutions that are performed by the C preprocessor, which is also responsible for processing trigraphs, #include's, #if's, concatenating line continuation, and replacing comments with white space. In some implementations the preprocessor is a separate program that is run before the compiler, and whether or not it really is a separate program in a given implementation, you should think of it that way because that is the way it works.

This is old, but if you want to see how truely the preprocessor is disconnected from C itself, look at this web site:
http://www.cs.tut.fi/~jkorpela/html/cpre.html

-Preston

Re: Question about #define

nfxs — Thu, 02 Oct 2008 06:48:22 GMT

Hi, all
Thanks for the answers.
Now i get it. I used macros only very little, so i was not aware of all its potential.
Now i will use it a little more careful
Regards