Re: _Bool on non-C99-conformant compilers

[Daniel J S. <dan...@ie...>]

On 08/28/2012 05:58 AM, Mojca Miklavec wrote:
> Hello,
>
> I exchanged a few emails off-list, but the following discussion should
> better move to the mailing list:
>
> On Tue, Aug 28, 2012 at 9:30 AM, Daniel J Sebald wrote:
>> On 08/27/2012 06:40 PM, Mojca Miklavec wrote:
>>> On Tue, Aug 28, 2012 at 12:27 AM, Daniel J Sebald wrote:
>>>> On 08/27/2012 04:30 PM, Mojca Miklavec wrote:
>>>>
>>>>> Do you have any idea about how to overcome _Bool being defined
>>>>> in C, but not in C++?
>>>>
>>>> C++ uses "bool", doesn't it?  If the code in question is a .cpp file,
>>>> "bool" is probably what should be used.
>>>
>>> Do you mean replacing this (which is what's currently in syscfg.h)
>>
>> Not really.  I was thinking more along the lines of just using "bool" if
>> writing C++ code.  Why is _Bool needed?
>
> The C++ code already uses bool. From my understanding, _Bool is never
> used in C++. But "syscfg.h" is apparently used for both C and C++ (I'm
> not sure about the exact include chain, but it somehow effects wxt's
> C++ compilation) and boolean values are needed in C.

OK.  There are a lot of dependencies in qt_term.cpp.


> On any given modern system with C99-conforming stdbool.h the code
> works perfectly now. It just includes that file and we're done. On all
> the other systems the current approach in "#else" part is wrong in my
> opinion:
>
> #if HAVE_STDBOOL_H
> # include<stdbool.h>
> #else
> # if ! HAVE__BOOL
> #  ifdef __cplusplus
> // this means: if _Bool doesn't exist in C, define _Bool in C++; why?
> typedef bool _Bool;
> #  else
> typedef unsigned char _Bool;
> #  endif
> # endif
> // why would one want to redefine bool, true and false in C++ when it
> is all already present?

I'm wondering that as well.

> // this currently breaks Solaris, Mac OS X 10.6 with Xcode 4.2, etc.
> # define bool _Bool
> # define false 0
> # define true 1
> # define __bool_true_false_are_defined 1
> #endif


>> Well, I'd say try to leave<syscfg.h>  out of the C++ file if nothing there
>> is needed.
>>
>> I'm not exactly understanding what needs to be done.  Please explain.
>
> That is also an option, but I don't know how syscfg.h ends up included
> in C++ code at all, and it might be that the file is needed for other
> purposes. That's a question for other developers. If the function is
> written properly, I don't find any problem with syscfg.h being
> included in C++ as well. It should be harmless (if problems are
> fixed).

Yes.  Plus there are ten C headers included in qt_term.cpp, which is too 
many to sort through.


> I slightly changed the suggestion that I sent you earlier, to:
>
> #if HAVE_STDBOOL_H
> # include<stdbool.h>
> #else
> # ifndef __cplusplus
> #  if ! HAVE__BOOL
>      typedef unsigned char _Bool;
> #  endif
> #  define bool _Bool
> #  define false 0
> #  define true 1
> # endif
> // the line below is probably not needed
> # define __bool_true_false_are_defined 1
> #endif

To check where it is used, I grepped and found the only instances in the 
"configure" file of all places.  It's a quite convoluted definition.


> You need to keep in mind that code like this one:
>
> /* suprisingly Cocoa version of wxWidgets does not define _Bool ! */
> #ifdef __WXOSX_COCOA__
> #define _Bool bool
> #endif
>
> probably resulted from a bug in autotools. Autotools figured out
> (wrongly) that _Bool was not defined in C and then ended up defining
>      #  define bool _Bool
> in C++, so "bool" stopped working in C++ altogether. By using newer
> autotools and by using the patch above, the code chunk above should
> not be needed. It was just a bad workaround (which worked, but didn't
> do the proper thing, and didn't help for Qt either).
>
> Similar symptoms might be true for this:
>
> /* May or may not fix a problem reported for Sun Studio compilers */
> #if defined(__SUNPRO_CC)&&  !defined __cplusplus&&  !defined(bool)
> #define bool unsigned char
> #endif

If a change ends up being made, check whether this definition actually 
ends up being the case when !defined __cplusplus&&  !defined(bool).  If 
so, this is extraneous.

Dan