Amit Kapila <amit.kapila16@gmail.com> writes:
> On Fri, Oct 25, 2019 at 9:55 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> However, we're not out of the woods, because lookee here in
>> ecpglib.h:
>> #ifndef bool
>> #define bool char
>> #endif /* ndef bool */
>> I'm more than slightly surprised that we haven't already seen
>> problems due to this conflicting with d26a810eb.
> I think it is because it never gets any imports from c.h.
On closer inspection, it seems to be just blind luck. For example,
if I rearrange the inclusion order in a file using ecpglib.h:
diff --git a/src/interfaces/ecpg/ecpglib/data.c b/src/interfaces/ecpg/ecpglib/data.c
index 7d2a78a..09944ff 100644
--- a/src/interfaces/ecpg/ecpglib/data.c
+++ b/src/interfaces/ecpg/ecpglib/data.c
@@ -6,8 +6,8 @@
#include <math.h>
#include "ecpgerrno.h"
-#include "ecpglib.h"
#include "ecpglib_extern.h"
+#include "ecpglib.h"
#include "ecpgtype.h"
#include "pgtypes_date.h"
#include "pgtypes_interval.h"
then on a PPC Mac I get
data.c:210: error: conflicting types for 'ecpg_get_data'
ecpglib_extern.h:167: error: previous declaration of 'ecpg_get_data' was here
It's exactly the same problem as we saw with pgtypeslib_extern.h:
header ordering changes affect the meaning of uses of bool, and that's
just not acceptable.
In this case it's even worse because we're mucking with type definitions
in a user-visible header. I'm surprised we've not gotten bug reports
about that. Maybe all ECPG users include <stdbool.h> before they
include ecpglib.h, but that doesn't exactly make things worry-free either,
because code doing that will think that these functions return _Bool,
when the compiled library possibly thinks differently. Probably the
only thing saving us is that sizeof(_Bool) is 1 on just about every
platform in common use nowadays.
I'm inclined to think that we need to make ecpglib.h's bool-related
definitions exactly match c.h, which will mean that it has to pull in
<stdbool.h> on most platforms, which will mean adding a control symbol
for that to ecpg_config.h. I do not think we should export
HAVE_STDBOOL_H and SIZEOF_BOOL there though; probably better to have
configure make the choice and export something named like PG_USE_STDBOOL.
regards, tom lane
