I'm converting some C code from Archimedies to Keil version 7.0 and I don't know why this error C129 is popping up. I thought is was because in Archimedies xdata came before uchar so I switched around all xdata variables in the Global.c and Global.h files but still had the error. So I inserted a new #define line above the error point but still have the error. Here is how the codes is written and the error message points to the BOLD text line: Global.c file #include "header.h" #include "global.h"
/* The following are BIT status errors */
uchar xdata arincReceive0Counter; uchar xdata arincReceive1Counter; uchar xdata CurrentlyUsedARINC;
Global.h file #define ARINC_CHAN0_CHK_BSY ARINC_CHAN0 + ARINC_CHK_BSY #define ARINC_CHAN0_USED ARINC_CHAN0 + ARINC_USED #define ARINC_CHAN1_CHK_BSY ARINC_CHAN1 + ARINC_CHK_BSY #define ARINC_CHAN1_USED ARINC_CHAN1 + ARINC_USED
extern uchar xdata arincReceive0Counter; extern uchar xdata arincReceive1Counter; extern uchar xdata CurrentlyUsedARINC;
Got any ideals?
Yes, I definitely recommend to always use include guards, since they are the only method where a used library may be rewritten to change it's required include files, without breaking the main application..
pray explain what guards have to do with "a used library may be rewritten"
Erik
Let's assume that I use a library written by someone else. It might be a crypto library, a compression library, ...
The library exports a number of fixed API for doing it's work.
However, a new version of the library may have changed it's internal implementation, resulting in a changed use of files included from the main library include file.
For example, it might have changed the internal storage from a dual-linked list to a RB-tree, using the STL <map> container.
Now, if the include file <map> does not contain a guard, and _my_ project does contain lines #include <map> for my own code, I would get a compilation error, since the file is suddently included multiple times.
With guards (and rest assured, the file <map> _is_ guarded), my code will not be affected, since my code will just continue using the data types declared in the library include file, without knowing that they _also_ makes use of the <map> type.
In this case, my example was regarding an include file supplied by the system and/or the compiler, but the exact same thing happens if I use two third-party libraries, and one of the third-party libraries is modified to make use of the other third-party library.
Third party might be bought code, "free" code or code shared with a different in-house product. However, it is code that is living it's own life, and someone else is responsible for maintaining and extending.
If you think life is easy without guards: Go into your compilers include directory tree and remove all guards. Most probably you will get a number of collisions you didn't knew that the guards silently solved for you.
I don't see guards as an optional extra. I see them as part of normal workmanship.