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?
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.