Preprocessor directives

In one of your source files, you should define __MAIN_C_ before including your header file. How else will the header file know when to use "extern" or not?

By the way - you should consider using symbols without any leading underscore. You are neither the C standard maintainer nor the compiler vendor...

I could be missing something, but what is the point of defining __MAIN_H in your code sample? Normally it's done to avoid multiple inclusion. But in order to achieve this you have to move the #endif from line 3 to the last line of your header file.

Of course I defined in the "MAIN_C_" in the "main.c" file. And you are right with the underscores. In my initial version I tried it without underscores, but without success. That's why I simply tried it this way. But now I removed them again.

In my opinion the problem comes from the "#define" statement. In the following code line the key word "extern" isn't marked bold in the IDE:

#ifndef MAIN_C_
  #define EX extern
#else
  #define EX
#endif

Normally the key word "extern" is displayed as bold text. When I remove the "#define" statement, it is bold again. This is for me an indicator, that there is something wrong.
Another question by the way: Is German also accepted? ;)
Greetings

I assumed that he had something inserted there, but now removed for brevity.

Anyway - most source code editors don't look for keywords in preprcessor lines - as soon as they see #define they color the full line using the "preprocessor" color. Same thing with comments - try to write keywords inside comments, and you still get the markup for a comment.

I'm pretty sure I'm coding in a common way

More to the point, you're following common, yet bad advice. This whole "EX" machinery (more commonly seen with "EXTERN" as the macro name) is a waste of energy, and it tends to break in quite nasty ways as soon as people start trying to extend it to explicitly initialized variables. In the end, this "trick" will hurt worse than the problem it claims to solve.

#ifndef ___MAIN_H_
#define ___MAIN_H_
#endif

That #endif is entirely in the wrong place for this work as a multiple inclusion guard.

I think that's what the 'C' FAQ means when they say,

"It is possible to use preprocessor tricks ... but it's not clear if this is worth the trouble"

c-faq.com/.../decldef.html

Thanks for your comments!
So what would you prefer? How would you solve the problem with the global variables?

I'm tryin it at the moment with this code in main.h:

#define MAIN_H_

#undef EX

#ifndef MAIN_C_
  #define EX extern
#else
  #define EX

//Prototypes and variable declarations...
//...

#endif //at the end of file

But this doesn't work too. I still need to declarate the variables in the main.c , otherwise they are not known.
Greetings

Like this ("include guard" omitted for clarity):

The header file contains only straightforward extern declarations:

// main.h
extern char tom;
extern int  ***;
extern long harry;

main.c contains the definitions and includes the header:

// main.c
#include "main.h"

char tom;
int  ***;
long harry;

Including the header here is important - it's what allows the compiler to detect any discrepancies!

Other .c files just include the header:

// other.c
#include "main.h"

// code can reference tom, ***, and/or harry...

Again, see: c-faq.com/.../decldef.html

If you still want to pursue the preprocessor business, the first thing to do is to examine the preprocessor output - see Andy's Handy Hint for Debugging Preprocessor Problems here: www.8052.com/.../read.phtml (it is not specific to 8052).

How would you solve the problem with the global variables?

By rejecting the conclusion that there were any problem to be solved there.