0

Sorry for the bad title, I'll try to describe my problem a bit better..

I work with a real-time OS. Since I have the task to test a new feature and our main RTOS does not support it yet, I will make a prototype based on another (until now not used) RTOS. This new RTOS brings its own header files which hosts many typedefs to generate abbreviations like ULONG, BOOL, INT, etc...

In our code-base there are typedefs that shall guarantee that, for example, an unsigned long is exactly 4 Bytes. And according to our styleguide those new types shall be used for any interface we produce.
Those typedefs unfortunately are named the same as the ones from the new RTOS (ULONG, INT, BOOL, ...).
The build-breaking thing is, that BOOL for example is once declared as unsigned char and once as int.
This leads to corruption of some function-headers where BOOL and other different types are used.

My question is, how can I make one of those two the "main" header and thus prefer it's typedefs over the ones of the other header-file?
And what other ways do you see to divide those two headers?

Since I only implement a prototype on the new RTOS, changing our base-types is seen as a less favored solution. Any help is appreciated and if you need further clarification, just let know!

edit:
ok, here's some code for further clarification:

RTOS_typedefs.h

...
typedef void VOID;
typedef unsigned char BOOL;
typedef int INT;
...


ownCodeBase_typedefs.h

...
#define void VOID
typedef int BOOL;
typedef int INT;

Now as you can see, the INT typedef is the same and causes no trouble.
The Void define collides with the void typedef in some files and the preprocessor produces the following:

typedef void void;

... which generates a compiler error.
The Bool typedef destroys my function-headers since in one file the RTOS-version is used and in the other file the typedef from our code base is used. The compiler generates two different signatures and the linker can't find the definition for one of them. -> another error is thrown

simmue
  • 170
  • 1
  • 8
  • 5
    Rather than trying to describe your code with a wall of text, it would be far easier to show us a code snippet that illustrates your problem. – Cory Kramer Jul 25 '17 at 11:29
  • 3
    the typedefs should live inside seperate namespaces, if this would be the case you wouldnt have a problem – 463035818_is_not_an_ai Jul 25 '17 at 11:30
  • Put your code-base typedef(s) into your namespace. – Richard Critten Jul 25 '17 at 11:35
  • CoryKramer, you're right, I added some code to clarify it a little bit. Thanks for the hint! I am aware that using separate namespaces would be one solution, but I'm only a student writing a thesis and the code base consists of something like 30+ big modules. Additionally I'm afraid that telling the bosses that the team won't work on the product in the next time and refactor code won't impress them. – simmue Jul 25 '17 at 12:32

1 Answers1

1

Manually overriding the typedefs with some preprocessor (ab)use is an option. 

/* Rename the OS version of 'BOOL' to something else */
#define BOOL osBOOL
#include <osheader>
#undef BOOL 
/* When myheader.h is included, BOOL is still free to be typedef'd'. */
#include myheader.h

The manual override will prevent the RTOS from overriding the meaning of BOOL in your application. Its typedef of BOOL will instead typedef osBOOL and any internal uses of BOOL are replaced by an osBOOL.

Repeat the paradigm for any other primitive abbreviation you wish to override the already existing OS-defined header type for.

Note that doing the reverse is also possible. If you have a general header that is included in all your project's files, you can #define macro BOOL there to something that is not reserved by the RTOS after including its headers. Then when you run typedef BOOL char the preprocessor will first translate BOOL into myBOOL, as well as every use of it in the code files including the header.

Also see this question for some related ideas.

aphid
  • 1,135
  • 7
  • 20
  • Thank you for the reply! I've already read about this approach but think that it's a bit hack-ish and hoped that there is some other method. Thanks for the link! – simmue Jul 25 '17 at 13:27