Warnings around booleans - Mailing list pgsql-hackers

From Andres Freund
Subject Warnings around booleans
Date
Msg-id 20150812084351.GD8470@awork2.anarazel.de
Whole thread Raw
Responses Re: Warnings around booleans  (Andres Freund <andres@anarazel.de>)
Re: Warnings around booleans  (Stephen Frost <sfrost@snowman.net>)
Re: Warnings around booleans  (Andres Freund <andres@anarazel.de>)
List 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
againstMAYBE).
 
  What I find slightly worrysome is that in gin_tsquery_consistent()  checkcondition_gin (returning GinTernaryValue) is
passedas 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.
Whichmean 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



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: optimizing vacuum truncation scans
Next
From: Marko Tiikkaja
Date:
Subject: Re: PL/pgSQL, RAISE and error context