I have two files fsm_right.c and fsm_left.c
in my main program, before any other header files, I have this
#define FSM 1
#ifdef FSM #ifdef FMSLEFT // note: currently undefined include "fsm_left.c" #else include "fsm_right.c" #endif #endif
the next line is
unsigned char author= "whatever";
The compiler spits up on the assignment line, with a C129 missing ';' before <string>
So I figured, something in fsm_right was incorrect. To test this, I commented out the include "fsm_right.c" (and this same thing happens with the <fsm_right.c> syntax. The program compiles without a problem. So I figured the problem was in fsm_right.c I edited fms_right.c and deleted EVERYTHING in it, so it is just a blank file.
And it *STILL* has the error. This is version 7.5 by the way. K&RC say that the include statement is replaced by the contents of the file.
What in the world is going on here? With the include commented out //include ..... it compiles fine. With the include NOT commented out, it gives the error WHETHER OR NOT there is anything in the body of the included file.
This makes no sense. Is there a bug in the pre-processor? environment is windows XP running Silabs IDE with the Keil 7.5 as the compiler. I've seen this before, could not figure it out and went a different direction, but now I need to have it this way.
The project consists of a main file, and a second C file with some constants and structures. I compile them seperately and link them. Now I need to build two new configurations, to be controlled by compile time switches. I don't want to put fsm_left and fsm_right into the structure file, because then I would have to set the define in that file, as well as the main file, and this can result in building the wrong device. The main file compiles code for 3 seperate products based on compile time switches. The 3 devices share a common set of structures, though not all of them are used by each build.
Andrew: I know. I typed this in rather than pasting code. That should have been
unsigned char author[]="whatever";
I just left the [] out when I typed it in for whatever reason.
The issue however is not about that. It is about the following lines, being inserted into a totally compiler error free file,\\
#ifdef FSM #ifdef FSMLEFT #include "fmsleft.c" #else #include "fsmright.c" #endif #endif
causing an error. Assume that FSM is defined, and FSMLEFT is not defined, then #include "fsmright.c" happens.
that causes an error, regardless of whether there is anything *in* the included file. it causes the same error if the include file is error free. And the line where the error is flagged happens to be the next line of code after the last #endif.
Can you get the compiler to generate pre-processor output, and inspect that?
Yes, you can: http://www.keil.com/support/man/docs/c51/c51_preprint.htm
"inspect that"
Always a good idea for preprocessor-related issues: www.8052.com/.../29152
http://www.keil.com/forum/57051/
It is about the following lines, being inserted into a totally compiler error free file, ... that causes an error, regardless of whether there is anything *in* the included file.
The problem is that being "compiler error free", all by itself, doesn't mean much of anything. It's entirely possible that there was quite a serious mistake in that file already, which just so happened to not trigger any compiler error. Don't laugh ... it happens.
Assume that FSM is defined, and FSMLEFT is not defined, then
Frankly, the way you're trying to handle #defines, I have to doubt that. So what happenes if you do away with all that, and just put a plain
#include "fsmright.c"
in there?
And the line where the error is flagged happens to be the next line of code after the last #endif.
Then there's a good chance the actual problem was in the last line before that freshly inserted construct. Or you created the problem by inserting that construct in the middle of some statement.
Thanks. I was not aware of preprint.
The issue is still a generic one, apparently the compiler can't handle #includes of a c file inside of an ifdef.
I will try a build with preprint and see what the heck it actually produces.
Hans:
I never have found the problem, but decided to create another header file and include it and move the #defines to it, and include it in both c files. That way I can conditionalize both c files and only have 1 place to maintain. Thanks for the slap up the side of the head..... Grin.
... and include it and move the #defines to it, and include it in both c files.
Yes, that would be the more conventional approach!
I've never been accused of being conventional :)