1

I am writing a C software for a microcontroller, the compiler is Microchip MCC18.

For test purposes, I have written a very simple program as follow:

.c file

#include "x.h"

char *now_clock;

.h file

extern char *now_clock;

With the above code I get a syntax error, but I don't know what is wrong. Any help?

Chris Smith
  • 18,244
  • 13
  • 59
  • 81
eepty
  • 19
  • 1
  • 2
  • Is this an ODR violation? Can you remove the 'char* now_clock' in the .c file? – Chris Smith Feb 06 '11 at 16:50
  • 5
    What error ?? Be more specific please! – RED SOFT ADAIR Feb 06 '11 at 16:52
  • 4
    Please include the actual syntax error you are getting. That code appears to be valid C to me, and compiles under GCC. – nelhage Feb 06 '11 at 16:56
  • The One Definition Rule applies only to C++, not C. And it would not be the problem in this case anyway, because of the "extern" in the header file. – zwol Feb 06 '11 at 17:24
  • The error is elsewhere, not with what you posted. Post the actual error message and teh line of code it references. You *do* need include guards in teh header file however. – Clifford Feb 06 '11 at 19:06
  • @Clifford: it is a good idea to have include guards, but as written, there is no problem with including the header many times. The problems occur when a header includes a `typedef` or `enum` (or, contrary to standard practice, if it includes actual (initialized) variable definitions). – Jonathan Leffler Feb 07 '11 at 02:36
  • @Jonathan: ... or a macro definition. Agreed, if this is the complete header and not a fragment. I was thinking that if he was getting an error message, and this was only a fragment then lack of guards and some other part of the file may be the cause. – Clifford Feb 08 '11 at 14:56
  • @Clifford: a compiler doesn't complain about a 'benign' macro definition where the token sequence is the same in both cases. Clearly, if you include the same file twice, the token sequence for any macros is the same each time - barring extraordinary contortions. So macros are not harmful either. But I agree that header guards are a good idea in general - I said as much in my first comment. We just know that we don't have the complete source of the problem in the material presented in the question. – Jonathan Leffler Feb 08 '11 at 15:08

2 Answers2

3

The code shown, which doesn't seem to have changed across the edit, compiles correctly for me on MacOS X 10.6.6 with GCC 4.5.2 under stringent warnings - as indeed it should do.

$ cat x.h
extern char *now_clock;
$ cat x.c
#include "x.h"

char *now_clock;
$ gcc -O -std=c99 -Wall -Wextra -pedantic -c x.c
$

The code in x.c shows correct style - it includes the header that declares the variable to cross-check the definition of the variable. You can also add an initializer to the definition in x.c without problems.

I conclude that you have over-simplified your example and lost the problem in the process.

Community
  • 1
  • 1
Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
  • Agreed: When I tried it, the only error this "very simple program" yields was a linker error *"unresolved external symbol _main"*, which is hardly surprising. – Clifford Feb 08 '11 at 15:01
0

You don't declare extern char* now_clock in the .c file which is what you are doing by including x.h in your .c. Remove #include "x.h" and you'll be fine.

Only include x.h in the .c files that want to access the variable.

Andrew T Finnell
  • 13,417
  • 3
  • 33
  • 49
  • 1
    Yes, you **do** include x.h in the file x.c so that you get a cross-check that the definition in x.c matches the declaration in x.h. – Jonathan Leffler Feb 06 '11 at 17:14
  • I suspect that in older C compilers what Andrew says applies. That is why there used to be a lot of [extern redefinitions](http://www.eng.cam.ac.uk/help/tpl/languages/C/teaching_C/node29.html) in header files – renick Feb 06 '11 at 17:53
  • @renick As it has been a long time since I did standard C this was my assumption still. But as Jonahtahn Leffler has proven, this is no longer needed. – Andrew T Finnell Feb 06 '11 at 18:07
  • You are right but I suspect that this PIC Compiler is still lightyears away from GCC 4.5 and C99 – renick Feb 06 '11 at 18:11