autoconf
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]