Grokbase › Groups › PostgreSQL › pgsql-hackers › November 2010
FAQ
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

Search Discussions

  • Michael Meskes at Nov 2, 2010 at 5:32 pm ⇧

    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
  • Itagaki Takahiro at Nov 4, 2010 at 1:45 am ⇧

    On Wed, Nov 3, 2010 at 2:19 AM, Michael Meskes 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
  • Robert Haas at Nov 4, 2010 at 1:17 pm ⇧

    On Wed, Nov 3, 2010 at 6:45 PM, Itagaki Takahiro wrote:
    On Wed, Nov 3, 2010 at 2:19 AM, Michael Meskes 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
  • Robert Haas at Nov 15, 2010 at 2:13 am ⇧

    On Wed, Nov 3, 2010 at 9:45 PM, Itagaki Takahiro wrote:
    On Wed, Nov 3, 2010 at 2:19 AM, Michael Meskes 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
  • Itagaki Takahiro at Nov 15, 2010 at 2:21 am ⇧

    On Mon, Nov 15, 2010 at 11:13, Robert Haas 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedNov 1, '10 at 3:17a
activeNov 15, '10 at 2:21a
posts6
users3
websitepostgresql.org...
irc#postgresql

3 users in discussion

Itagaki Takahiro: 3 posts Robert Haas: 2 posts Michael Meskes: 1 post

Content

People

Support

Translate

site design / logo © 2023 Grokbase