Warnings around booleans

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org, Stephen Frost <sfrost(at)snowman(dot)net>
Subject: Warnings around booleans
Date: 2015-08-12 08:43:51
Message-ID: 20150812084351.GD8470@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Forcing our bool to be stdbool.h shows up a bunch of errors and
warnings:

1) gin stores/queries some bools as GinTernaryValue.

Part of this is easy to fix, just adjust GinScanKeyData->entryRes to
be a GinTernaryValue (it's actually is compared against MAYBE).

What I find slightly worrysome is that in gin_tsquery_consistent()
checkcondition_gin (returning GinTernaryValue) is passed as a
callback that's expected to return bool. And the field
checkcondition_gin is returning (GinChkVal->check[i]) actually is a
ternary.

2) help_config.c has a member named 'bool' in a local struct. That
doesn't work well if bool actually is a macro. Which mean that whole
#ifndef bool patch in c.h wasn't exercised since 2003 when
help_config.c was created...

=> rename field to bool_ (or _bool but that looks a wee close to C's _Bool)

3) The 'bypassrls' boolean in AlterUser() is queried strangely. There are two
complaints:

bool bypassrls = -1;

it's a boolean.

else if (authform->rolbypassrls || bypassrls >= 0)
{
if (!superuser())
ereport(ERROR,
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
errmsg("must be superuser to change bypassrls attribute")));
}
...
if (bypassrls >= 0)
{
new_record[Anum_pg_authid_rolbypassrls - 1] = BoolGetDatum(bypassrls > 0);
new_record_repl[Anum_pg_authid_rolbypassrls - 1] = true;
}

if it's a boolean, that's always true.

It's not entirely clear to me why this was written that way. Stephen?

3) vacuumdb.c stores -1's in a bool (result) in vacuum_one_database().

=> convert to an int

4) _tableInfo->relreplident is a bool, should be a char

Greetings,

Andres Freund

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Tiikkaja 2015-08-12 09:07:43 Re: PL/pgSQL, RAISE and error context
Previous Message Simon Riggs 2015-08-12 08:11:42 Re: optimizing vacuum truncation scans