Hi all. My operating system runs on x86 and 68k machines and I'm having some difficulty with the x86 C code. Im using Watcom 11.0c (Im too lazy to upgrade ) and when using macros (#ifdef, #ifndef) I get an error message "Matching #endif in other source file". The 68k C compiler dosnt have a problem with this. Im using a windows batch file to build my OS. The include directory is at the source root and the source files are like this.
A section starting with #ifdef / #ifndef continues until a #endif directive is found. The compiler is telling you that the section beginning at your #ifdef / #ifndef has its matching #endif in a different source file, i.e. you either didn't close it or tried to include a file within your #ifdef / #ifndef section.
Every good solution is obvious once you've found it.
1) Check that you don't #include within your #ifdef / #endif sequence. Check that you don't have a forgotten #ifdef / #ifndef / #endif lurking around somewhere (use 'grep').
2) Try gcc -E to stop compiling after the preprocessor stage (i.e., after includes, macro expansions, and #ifdef handling).
Every good solution is obvious once you've found it.
Solar wrote:1) Check that you don't #include within your #ifdef / #endif sequence. Check that you don't have a forgotten #ifdef / #ifndef / #endif lurking around somewhere (use 'grep').
It's perfectly acceptable to #include within an #if/#ifdef/#ifndef. Those are supposed to nest properly, and compilers that warn about #endif in a separate file do so because it's almost always a forgotten #endif. If a preprocessor cannot deal with #include withing #if/#ifdef/#ifndef block it's crap and should be replaced with something modern.
While I usually care about standards, in this case I'm going to stand by that opinion even if somebody points out that a certain standard disallows such constructs.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
mystran wrote:It's perfectly acceptable to #include within an #if/#ifdef/#ifndef. Those are supposed to nest properly, and compilers that warn about #endif in a separate file do so because it's almost always a forgotten #endif. If a preprocessor cannot deal with #include withing #if/#ifdef/#ifndef block it's crap and should be replaced with something modern.
I do this quite frequently, I didn't even know such compilers existed that didn't support this..
Are you sure it wasn't just misconfigured Mike359? (I have never used OpenWatcom).
Twitter: @canadianbryan. Award by smcerm, I stole it. Original was larger.
I didn't say that include-in-ifdef was "illegal", just that his problem could be in one of his include files instead of the source file he was looking at.
Every good solution is obvious once you've found it.
Well I was configured correctly. I also have warnings set as errors. All I did was delete my Watcom directory and install the Open Watcom overtop of it and when I ran my build batch file it worked correctly.
) and when using macros (#ifdef, #ifndef) I get an error message "Matching #endif in other source file". The 68k C compiler dosnt have a problem with this. Im using a windows batch file to build my OS. The include directory is at the source root and the source files are like this.
