There are some "== true" in the codes, but they might not be safe
because all non-zero values are true in C. Is it worth cleaning up them?

src/backend/access/gin/ginget.c(1364):#define GinIsVoidRes(s)		(
((GinScanOpaque) scan->opaque)->isVoidRes == true )
src/backend/access/gist/gistproc.c(383):		if (allisequal == true && (
src/backend/commands/sequence.c(1107):		Assert(new->is_cycled == false
|| new->is_cycled == true);
src/backend/tsearch/regis.c(251):				if (mb_strchr((char *) ptr->data,
c) == true)
src/backend/utils/adt/geo_ops.c(3899):	for (i = start; i < poly->npts
&& res == true; i++)
src/backend/utils/adt/geo_ops.c(3975):		for (i = 0; i < polyb->npts &&
result == true; i++)
src/backend/utils/adt/tsrank.c(112):	if (item->prefix == true)
src/backend/utils/adt/tsvector_op.c(628):	if (res == false &&
val->prefix == true)
src/include/c.h(475):#define BoolIsValid(boolean)	((boolean) == false
|| (boolean) == true)
src/bin/psql/print.c(832):					if (opt_border != 0 ||
format->wrap_right_border == true)
src/interfaces/ecpg/ecpglib/connect.c(168):	if (con->autocommit ==
true && strncmp(mode, "off", strlen("off")) == 0)
src/interfaces/ecpg/preproc/ecpg.addons(356):		if (compat ==
ECPG_COMPAT_INFORMIX_SE && autocommit == true)
src/interfaces/ecpg/preproc/ecpg.c(310):					ptr2ext[3] = (header_mode
== true) ? 'h' : 'c';
src/interfaces/ecpg/preproc/ecpg.c(327):					ptr2ext[1] = (header_mode
== true) ? 'h' : 'c';

-- 
Itagaki Takahiro

On Mon, Nov 01, 2010 at 12:17:02PM +0900, Itagaki Takahiro wrote:
> There are some "== true" in the codes, but they might not be safe
> because all non-zero values are true in C. Is it worth cleaning up them?
> ...
> src/interfaces/ecpg/ecpglib/connect.c(168):	if (con->autocommit ==
> true && strncmp(mode, "off", strlen("off")) == 0)
> src/interfaces/ecpg/preproc/ecpg.addons(356):		if (compat ==
> ECPG_COMPAT_INFORMIX_SE && autocommit == true)
> src/interfaces/ecpg/preproc/ecpg.c(310):					ptr2ext[3] = (header_mode
> == true) ? 'h' : 'c';
> src/interfaces/ecpg/preproc/ecpg.c(327):					ptr2ext[1] = (header_mode
> == true) ? 'h' : 'c';

I actually see no reason why these variables are not defined as bool instead of
int, so I changed this. Hopefully I found all of them.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at googlemail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

On Wed, Nov 3, 2010 at 2:19 AM, Michael Meskes <meskes(at)postgresql(dot)org> wrote:
> On Mon, Nov 01, 2010 at 12:17:02PM +0900, Itagaki Takahiro wrote:
>> There are some "== true" in the codes, but they might not be safe
>> because all non-zero values are true in C. Is it worth cleaning up them?

Here is a proposed cleanup that replaces "boolean == true" with "boolean".
I didn't touch "== false" unless they are not in pairs of comparisons
with true because comparison with false is a valid C code.

Note that I also changed "boolean != true" in pg_upgrade,
but I didn't change ones in xlog.c because it might check
corrupted fields in control files.

>> src/interfaces/ecpg/preproc/ecpg.c(310):
>>    ptr2ext[3] = (header_mode == true) ? 'h' : 'c';
> I actually see no reason why these variables are not defined as bool instead of
> int, so I changed this. Hopefully I found all of them.

I added an additional cleanup to 'header_mode' in ecpg; I changed the type
from bool to char to hold 'h' or 'c'. Do you think it is reasonable?

-- 
Itagaki Takahiro

On Wed, Nov 3, 2010 at 6:45 PM, Itagaki Takahiro
<itagaki(dot)takahiro(at)gmail(dot)com> wrote:
> On Wed, Nov 3, 2010 at 2:19 AM, Michael Meskes <meskes(at)postgresql(dot)org> wrote:
>> On Mon, Nov 01, 2010 at 12:17:02PM +0900, Itagaki Takahiro wrote:
>>> There are some "== true" in the codes, but they might not be safe
>>> because all non-zero values are true in C. Is it worth cleaning up them?
>
> Here is a proposed cleanup that replaces "boolean == true" with "boolean".
> I didn't touch "== false" unless they are not in pairs of comparisons
> with true because comparison with false is a valid C code.

It looks like you have one or two irrelevant whitespace changes in ecpg.c.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Wed, Nov 3, 2010 at 9:45 PM, Itagaki Takahiro
<itagaki(dot)takahiro(at)gmail(dot)com> wrote:
> On Wed, Nov 3, 2010 at 2:19 AM, Michael Meskes <meskes(at)postgresql(dot)org> wrote:
>> On Mon, Nov 01, 2010 at 12:17:02PM +0900, Itagaki Takahiro wrote:
>>> There are some "== true" in the codes, but they might not be safe
>>> because all non-zero values are true in C. Is it worth cleaning up them?
>
> Here is a proposed cleanup that replaces "boolean == true" with "boolean".
> I didn't touch "== false" unless they are not in pairs of comparisons
> with true because comparison with false is a valid C code.
>
> Note that I also changed "boolean != true" in pg_upgrade,
> but I didn't change ones in xlog.c because it might check
> corrupted fields in control files.
>
>>> src/interfaces/ecpg/preproc/ecpg.c(310):
>>>    ptr2ext[3] = (header_mode == true) ? 'h' : 'c';
>> I actually see no reason why these variables are not defined as bool instead of
>> int, so I changed this. Hopefully I found all of them.
>
> I added an additional cleanup to 'header_mode' in ecpg; I changed the type
> from bool to char to hold 'h' or 'c'. Do you think it is reasonable?

I looked at this but found that part a bit too clever for its own good.

So committed the rest, plus an additional one-line change to psql's
print.c to avoid making the two accesses to format->wrap_right_pointer
inconsistent with each other.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, Nov 15, 2010 at 11:13, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> I added an additional cleanup to 'header_mode' in ecpg; I changed the type
>> from bool to char to hold 'h' or 'c'. Do you think it is reasonable?
>
> I looked at this but found that part a bit too clever for its own good.
>
> So committed the rest, plus an additional one-line change to psql's
> print.c to avoid making the two accesses to format->wrap_right_pointer
> inconsistent with each other.

Thanks!

-- 
Itagaki Takahiro