|
From: Mojca M. <moj...@gm...> - 2012-09-19 00:24:21
|
On Tue, Sep 18, 2012 at 8:48 PM, Ethan A Merritt wrote:
>
> === BOOLEANS ===
>> Mojca Miklavec <moj...@gm...>
>> Definitions of BOOL are still problematic (and configuration is broken
>> on Solaris, older Macs, ...).
>
> My understanding of the situation on Solaris is that no single fix will
> work for all versions of Solaris.
I admit that I don't know enough of Solaris, but the current approach with
#if defined(__SUNPRO_CC)
and so on (possibly for every single compiler on the planet) is
somewhat doomed to fail.
The problematic code is not the solaris-specific one, but the whole
block in src/syscfg.h starting with #if HAVE_STDBOOL_H.
The reason why 99.9% users don't notice any problem is because of this chunk:
#if HAVE_STDBOOL_H
# include <stdbool.h> /* this part is OK and covers 99% users */
#else
/* here is where it gets problematic/wrong; it works/workeded only
until C++ code has been added ... */
#fi
Most users never see the problematic else part. In principle that part
should work for everyone (even thouse with HAVE_STDBOOL_H defined to
true), but currently that is not the case.
> The versions differ from each other,
> and the requirements for C++ reportedly conflict with those for C.
True. The main problem is that one can have _Bool and the other one
not. Actually, there is no reason why C++ would need a "_Bool" type if
it already has "bool". So most of the time it's only a question of
whether _Bool is defined in C. But the conditional behaves as if _Bool
either has to be defined in both C/C++ or in none of them, and then
tries to do
# define bool _Bool
in C++, that is: break a previously working "bool" by redefining it to
a nonexistent "_Bool".
> But I'm working from ignorance, relying on Solaris users to provide help.
> I have 2 (3?) times previously applied patches that were submitted to
> handle Bool on some version of Solaris, and each time people reported
> that the change caused breakage on other systems. So unless someone has
> a patch that has been well tested on multiple versions of Solaris,
> I won't touch this.
Why not trusting developers of gnulib with a wide user base and their
code being used on most exotic system?
Or simply use the most trivial code that works?
My guess would be that the following should work (or at least cover 9
out of 10 currently problematic cases):
#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
#endif
but then again, taking code from gnulib should be a much better tested
solution. (If any system lacks "bool" in C++, the code above won't
cover that.)
> It is of course unfortunate that the Solaris compilers have a problem
> with standard C/C++ Booleans. It is likewise unfortunate that MSVC isn't
> ANSI-compliant with regard to initializing named fields in a structure,
> and unfortunate that some platforms lack a usable version of snprintf().
> We do try to accommodate in the source code where possible, but at some
> point it's just not worth the effort.
>
> Anyhow, this is clearly a long-term issue and not something that can
> quickly be patched for 4.6.1.
Given the broad number of exotic software where this needs to be tested ...
I agree, putting a patch into trunk might actually be a safer bet.
Mojca
PS: current code from gnulib, with comments stripped off:
#if defined __BEOS__ && !defined __HAIKU__
# include <OS.h> /* defines bool but not _Bool */
# undef false
# undef true
#endif
#ifdef __cplusplus
# define _Bool bool
# define bool bool
#else
# if defined __BEOS__ && !defined __HAIKU__
# if !HAVE__BOOL
typedef bool _Bool;
# endif
# else
# if !defined __GNUC__
# define _Bool signed char
# else
# if !HAVE__BOOL
typedef enum { _Bool_must_promote_to_int = -1, false = 0, true = 1 } _Bool;
# endif
# endif
# endif
# define bool _Bool
#endif
#ifdef __cplusplus
# define false false
# define true true
#else
# define false 0
# define true 1
#endif
#define __bool_true_false_are_defined 1
|