Amit Kapila <amit.kapil...@gmail.com> writes: > On Fri, Oct 25, 2019 at 9:55 PM Tom Lane <t...@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