_Bool on non-C99-conformant compilers

[Mojca M. <moj...@gm...>]

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.

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

> This is some strange code.  "typedef bool _Bool" followed by "define bool
> _Bool".  Strange.

That part I understand. A lot of systems have _Bool already defined by
compiler. On those systems gnuplot only uses
    #define bool _Bool
where _Bool comes from compiler. On other even more exotic systems
that don't know anything about _Bool it uses
    #typedef unsigned char _Bool
    #define bool _Bool
but that looks OK to me. OK, one could use just
    #typedef unsigned char bool
if that would change anything ...

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

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

This completely avoids _Bool in C++, it is only used in C to define
"bool". This approach solved the problem on Solars for me, and the
user who reported a problem on Mac OS X 10.6 said it solved the
problem for him as well.

The complete patch as suggested by me is here:
    http://sourceforge.net/tracker/?func=detail&aid=3562307&group_id=2055&atid=302055
(with all the links)

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


I would like to request if someone could take a closer look at the
patch. I don't have enough knowledge about different compilers to
claim that it would really solve all problems, but it already looks
much better. At least on two systems where current functionality is
broken (solaris, Mac OS X 10.6) the problem has been fixed.

Mojca