CUnit.h #define BOOL int confliction?

  • jianjunwang

    jianjunwang - 2004-12-27

    we oftern define BOOL as int, there is a problem in an embeded enviroment where BOOL is defined as char. as the test framework are also heavily depended on BOOL, so can sb give me a suggestion on this problem?

    • Jerry S.

      Jerry S. - 2005-04-19

      On one level, this points out a deficiency with the current definitions of common macros (BOOL, TRUE, FALSE) in the current version (2.0) of CUnit. Other public names in CUnit have been prefixed with 'CU_' to avoid clashes with client code. This probably should be extended to these macro names also.

      It sounds like you'll have to build CUnit with BOOL pre-defined (e.g. on the compiler command line) as char. You could also #include the appropriate embedded header(s) in CUnit.h before any of the macro definitions to make sure the proper definitions are used.

      Not sure if this will be helpful. Sounds like a typical example of cross-platform hell.

    • Mike Whittaker

      Mike Whittaker - 2005-06-29

      Sounds like CUnit should look at a 'configure' setting to determine use of a Boolean type, and then either use the existing one or create its own.

  • James Cleveland

    James Cleveland - 2010-05-27

    I would actually like CUnit to be operating and platform independent.

    From my personal experience, it is best to actually isolate all of the data
    types to a single file, such as:

    This will allow all of the types to be defined in one location and all of the
    compiler/platform specifics to be resolved in one location.

    I have actually done this for the following compilers and operating system:
    Microsoft C/C++ (Windows XP Pro)
    GNU C (SuSE Linux Enterprise Edition 11)
    C18 (Microchip C18 compiler for embedded systems)

    If you want, I would love to share this functionality with CUnit, so that it
    could become a more cross-platform tool.


Log in to post a comment.