[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_HEADER_STDBOOL: checking for _Bool separately for C and C++
From: |
Mojca Miklavec |
Subject: |
Re: AC_HEADER_STDBOOL: checking for _Bool separately for C and C++ |
Date: |
Tue, 28 Aug 2012 19:58:55 +0200 |
Dear Autoconf developers,
I would like to reparaphrase my question from last time.
Following the advice from Autoconf manual:
http://www.delorie.com/gnu/docs/autoconf/autoconf_50.html:
The following code in gnuplot breaks compilation on at least two
systems that don't conform to C99 (Sparc Solaris 9 with Sun Studio 12,
Mac OS X 10.6 with Xcode 3.2).
<<<<< (quote)
Macro: AC_HEADER_STDBOOL
If `stdbool.h' exists and is conformant to C99, define HAVE_STDBOOL_H
to 1; if the type _Bool is defined, define HAVE__BOOL to 1. To fulfill
the C99 requirements, your `system.h' should contain the following
code:
#if HAVE_STDBOOL_H
# include <stdbool.h>
#else
# if ! HAVE__BOOL
# ifdef __cplusplus
typedef bool _Bool;
# else
typedef unsigned char _Bool;
# endif
# endif
# define bool _Bool
# define false 0
# define true 1
# define __bool_true_false_are_defined 1
#endif
>>>>> (end of quote)
My suggestion would be to change this 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
// not really needed except to "conform with C99"
# define __bool_true_false_are_defined 1
#endif
otherwise a common situation in which _Bool is defined in C, but not
in C++, ends up with C++ compiler seeing:
// remember that _Bool is not defined in C++, it's only defined in C
// on the other hand, all of bool/false/true are known to C++, so I
don't see the need to redefine them all
# define bool _Bool
# define false 0
# define true 1
# define __bool_true_false_are_defined 1
and then any usage of "bool" in C++ breaks with "_Bool is not defined".
I suggested to do this change in gnuplot, but I would like to hear
your feedback as well, and possibly suggest improving the suggestion
in your official manual. I don't have that much experience with
different compilers, so it might be that I overlooked some cases. But
current solution is definitely not satisfactory. One problem with
unrecognized _Bool has been fixed not so long ago (between versions
2.65 and 2.68), with
2010-08-24 Paul Eggert <address@hidden>
AC_HEADER_STDBOOL: avoid spurious failure with modern xlc
* lib/autoconf/headers.m4 (AC_HEADER_STDBOOL): ...
2010-08-23 Eric Blake <address@hidden>
AC_HEADER_STDBOOL: avoid spurious clang failure
* lib/autoconf/headers.m4 (AC_HEADER_STDBOOL): Drop gcc ...
but this problem with weird bool/_Bool (re)definitions still prevents
compiling on some platforms, most notably older Mac OS X and Solaris.
Thank you very much,
Mojca
On Sun, Aug 26, 2012 at 2:47 PM, Mojca Miklavec wrote:
> Hello,
>
> A sparc solaris user reported a _Bool-related problem to gnuplot tracker.
>
> Long story short: stdbool.h is absent, _Bool is defined in C, but not
> in C++. Current header file in gnuplot sources which is used both in C
> and C++ goes like
>
> # if ! HAVE__BOOL
> # ifdef __cplusplus
> typedef bool _Bool;
> # else
> typedef unsigned char _Bool;
> # endif
> # endif
>
> But there is a problem. If
> AC_HEADER_STDBOOL
> is called with C compiler, it would figure out that _Bool is defined
> and thus skip defining _Bool in C++. If the macro is called with C++
> compiler, it would figure out that _Bool is undefined and try to
> define it for C as well. In either case compilation fails.
>
> My question is: what is the proper way to test for existence of _Bool
> in C and C++ separately? Something like this should work in the header
> file:
>
> # ifdef __cplusplus
> # if !HAVE__BOOL_IN_CXX
> typedef bool _Bool;
> # endif
> # else
> # if !HAVE__BOOL_IN_C
> typedef unsigned char _Bool;
> # endif
> # endif
>
> but I don't know what would be the proper way to get HAVE__BOOL_IN_CXX
> & HAVE__BOOL_IN_C without completely (re)defining AC_HEADER_STDBOOL
> macro.
>
> Thank you,
> Mojca