Re: _Bool on non-C99-conformant compilers

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

On Tue, Aug 28, 2012 at 5:50 PM, Daniel J Sebald wrote:
> On 08/28/2012 05:58 AM, Mojca Miklavec wrote:
>>
>> 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.

I have just found this:
    http://www.velocityreviews.com/forums/t316556-stdbool-h-and-backward-compatibility.html

"The
Autoconf manual seems to suggest that the following code be used in
one's program instead of #include <stdbool.h>:"

(and then the same code as in gnuplot)

I believe that the variable just mimics part of C99 and gnuplot
shouldn't need it at all. And it looks like a bad advice to me.

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

I'm 99% sure that the first patch for Mac is not needed any more (and
I have exact explanation why it was needed before). I don't have
reliable explanation for this second Sun patch, but I'm unable to
think of a case where it would be needed. The compilation on Solaris 9
Sparc with Sun Studio 12 worked with the patch that I sent (without
that extra "may or may not fix" patch).

Mojca