BOOL typedef redefinition when using LASlib

Question

The problem may look familiar but I think it still is somewhat different from the questions asked before on the same topic (although the 'solution' may be the same, i.e. there is no real fix other than to mess with the 3rd party codebase)

Here goes:

A portable C/C++ framework builds on Linux and Windows. It makes use of

the Microsoft C type BOOL that is included in winwindef.h, part of the Windows Platform SDK. the underlying type is 'int', which makes sense if you're defining values '1' as 'TRUE' and '0' as 'FALSE'.
```
#ifdef __cplusplus
  extern "C" {
#endif
...
typedef int                 BOOL;
...
#endif
```
with a preprocessor branch, for linux BOOL is sensibly typedef'ed as an int (int32_t to be exact) to preserve bytesize congruence between data representations. (I know, this is not sufficient and endedness is swapped, but most code remains simple.)
```
typedef int32_t             BOOL;
```

This platform code is proprietary ( me as author ) so changes can be made.

When a downstream lib or application wants to include LASlib (a part of LAStools) at https://github.com/LAStools/LAStools/tree/master/LASlib the compiler flags conflicting BOOL types, because LASlib contains a file named 'mydefs.hpp' that, when compiled under Windows uses an int as underlying type, but for linux seems to prefer the C++ 'bool'.

  #if defined(_MSC_VER) && (_MSC_VER < 1300) || defined (__MINGW32__)
  typedef int                BOOL;
  #else
  typedef bool               BOOL;
  #endif

I'm not a Microsoftie, but this is completely backwards (see also Using boolean values in C). I can imagine that the linux code produces smaller data fragments with platform branches everywhere but imho that should be left to the compiler. Also, the preprocessor guards aren't something I should manipulate (and would cause mayhem in CMake land) so I'm sort of stuck with this.

So now I'm faced with a dilemma;

change the LASlib code (which I'm not keen on, it's supposed to be 3rd party)
pretend that BOOL should be 'bool' in linux for the entire framework, but that means mapping a C++ type construct into a C type, giving up datasize stability, and obviously tomorrow another lib can retype it as a PlanetCookooDevice class type, so it doesn't solve the real problem.

I've read the answers to Typedef redefinition with different types ('signed char' vs 'bool') and BOOL redefinition after including minwindef.h but I feel the issue is more serious.

So, is there some sort of catch-all for conflicting types in the global namespace, or even at 'C' level? LASlib is a C++ header-only lib, but I can't extern "C" the entire thing either.

Are you locked to C89? Otherwise, since C99 there is absolutely no reason to think that the `bool` type is somehow a C++ thing ... See [ ``](http://man7.org/linux/man-pages/man0/stdbool.h.0p.html). — unwind, Nov 19 '19 at 10:38
Ok, true, I'm aiming for C99 compat but I guess old habbits never die. Still, the issue is a bit broader than just this case with 'BOOL' which is a C patch from decades ago. — StarShine, Nov 19 '19 at 10:43
I could go through the codebase and effectively split usage of bool, BOOL and _Bool. While not looking forward to that, it also doesn't solve any issues. Linking to other libs can potentially be problematic without having control to mitigate, other than to change the libs themselves.. — StarShine, Nov 19 '19 at 10:48
@StarShine: `_Bool` is not needed in your case. C99 only introduced that because there's existing C89 code which had `typedef bool int`. They didn't want to break that code. `#include ` is the C99 way of saying "`bool` is fine for me", and that's compatible with C++11. — MSalters, Nov 19 '19 at 10:59

score 0 · Accepted Answer · answered Nov 27 '19 at 08:35

It seems that there is no 'real' solution, i.e. double type definitions in the global namespace will clash if they are both defined in (separate) 3rd party libs and you want to pass these as dependencies for downstream projects. They should have been namespaced by their respective authors.

My current 'workaround' is to avoid the problem by making sure my use of BOOL is restricted to windows-only code, i.e. moving platform specific parts behind #ifdef guards. In some cases, this means wrapping/retyping function return values just because. Ugly, but it works.

BOOL typedef redefinition when using LASlib

1 Answers1