Re: TRUE and true

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: a(dot)korotkov(at)postgrespro(dot)ru
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: TRUE and true
Date: 2017-06-23 02:00:42
Message-ID: 20170623.110042.63983155.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Thu, 22 Jun 2017 15:35:13 +0300, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> wrote in <CAPpHfdtsF13YM1jbKCDBrdeC2Da5vs9Ca6sL4rwRj6=h1ACZgw(at)mail(dot)gmail(dot)com>
> On Thu, Jun 22, 2017 at 2:09 PM, Kyotaro HORIGUCHI <
> horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>
> > Hello, I have a maybe-silly question.
> >
> > What makes us have both TRUE/true or FALSE/false as constants of
> > bool?
> >
> > The following definitions in c.h didn't mess anything up.
> >
> > #define TRUE true
> > #define FALSE false
> >
>
> +1
> I don't know any policy about where to use TRUE and FALSE over true and
> false.
>
> # NIL seems causing similar mess.
> >
>
> NIL is used for lists, while NULL is used for other pointers.
> That may cause redundant, but at least there is clear policy.

Yes, I know and I like it personally, but NULL is sometimes used
with list pointers.

Looking on the face NIL === NULL is not proved but "if (!list)"
is seen frequently. Compler doesn't distingush them and actually
they harm nothing. This is all right but these facts make me
doubt of the significance of NIL.

Anyway, I don't mean that NIL ought to be removed immediately. It
will be naturally resolved when we migrate to pure C++ world
someday... ?

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2017-06-23 02:02:35 Re: TRUE and true
Previous Message Michael Paquier 2017-06-23 01:56:07 Re: Fast promotion not used when doing a recovery_target PITR restore?