Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
> On 4/5/17 01:20, Tom Lane wrote:
>> $ cat test.c
>> typedef char bool;
>> typedef char bool;
>> $ gcc -c test.c
>> test.c:2: error: redefinition of typedef 'bool'
>> test.c:1: note: previous declaration of 'bool' was here
> But the above is not how the current code looks.
No, but it is what the proposed 0001a patch would result in.
The experiments I just did prove that F25's gcc is cheating like mad in
its implementation of "#include <stdbool.h>". I suspect that it's somehow
turning off the warning that you ought to get about redefining typedef
bool, as well, though I'm very unclear on how. In any case we don't need
the extra typedef and should leave it out.
> So if you get stdbool.h first, then c.h does nothing. If you get c.h
> first, then the macro from stdbool.h will mask the c.h typedef.
Right, and *either* of those is disastrous if sizeof(_Bool) isn't 1.
> Where this gets really fun is when you include other header files
> between, say, postgres.h and selinux/label.h, because then the function
> definitions from those header files will be incompatible before and
> after the stdbool.h inclusion. Which indeed currently leads to the
> following compilation error:
The compilation complaint comes from the fact that we have
static bool
sepgsql_needs_fmgr_hook(Oid functionId)
appearing after the inclusion of <stdbool.h>, causing it to mean
something else than what a Postgres programmer would expect.
The other headers aren't at issue really.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
