Horton

Thread

Commits

  1. Fix silly initializations (cosmetic only).

  2. Fix ecpglib.h to declare bool consistently with c.h.

  1. [PATCH] gcc warning 'expression which evaluates to zero treated as a null pointer'

    didier <did447@gmail.com> — 2019-11-13T10:29:26Z

    Hi,
Trivial patch:
- remove a gcc warning (since commit 7a0574b5)
expression which evaluates to zero treated as a null pointer constant of
      type 'HeapTuple' (aka 'struct HeapTupleData *')

- always use "if (newtuple == NULL)" rather than mixing !newtuple and
newtuple == NULL

Regards
Didier

  2. Re: [PATCH] gcc warning 'expression which evaluates to zero treated as a null pointer'

    Tom Lane <tgl@sss.pgh.pa.us> — 2019-11-13T19:52:48Z

    didier <did447@gmail.com> writes:
> Trivial patch:
> - remove a gcc warning (since commit 7a0574b5)
> expression which evaluates to zero treated as a null pointer constant of
>       type 'HeapTuple' (aka 'struct HeapTupleData *')

Hmm, the initializations "HeapTuple newtuple = false" are certainly
bogus-looking and not per project style; I wonder who's to blame for
those?  (I do not see what 7a0574b5 would have had to do with it;
that didn't affect any backend code.)

> - always use "if (newtuple == NULL)" rather than mixing !newtuple and
> newtuple == NULL

Don't particularly agree with these changes though.  "if (!ptr)" is
a very common C idiom, and no programmer would tolerate a compiler
that warned about it.

			regards, tom lane

  3. Re: [PATCH] gcc warning 'expression which evaluates to zero treated as a null pointer'

    didier <did447@gmail.com> — 2019-11-13T20:38:12Z

    Hi,
On Wed, Nov 13, 2019 at 8:52 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> didier <did447@gmail.com> writes:
> > Trivial patch:
> > - remove a gcc warning (since commit 7a0574b5)
> > expression which evaluates to zero treated as a null pointer constant of
> >       type 'HeapTuple' (aka 'struct HeapTupleData *')
>
> Hmm, the initializations "HeapTuple newtuple = false" are certainly
> bogus-looking and not per project style; I wonder who's to blame for
> those?  (I do not see what 7a0574b5 would have had to do with it;
> that didn't affect any backend code.)

My mistake it's not gcc but clang for JIT, maybe because it could
change false definition?
clang version: 6.0.0-1ubuntu2
clang -E output before 7a0574b5
HeapTuple newtuple = 0;
with 7a0574b5
HeapTuple newtuple = ((bool) 0);

>
> > - always use "if (newtuple == NULL)" rather than mixing !newtuple and
> > newtuple == NULL
>
> Don't particularly agree with these changes though.  "if (!ptr)" is
> a very common C idiom, and no programmer would tolerate a compiler
> that warned about it.
There's no warning, it's stylistic. In the same function there's both
forms a couple of lines apart: "if (!ptr)" follow by "if (ptr ==
NULL)", using only one form is smother on the brain, at least mine.

Regards
Didier

  4. Re: [PATCH] gcc warning 'expression which evaluates to zero treated as a null pointer'

    Tom Lane <tgl@sss.pgh.pa.us> — 2019-11-13T21:01:19Z

    didier <did447@gmail.com> writes:
> clang -E output before 7a0574b5
> HeapTuple newtuple = 0;
> with 7a0574b5
> HeapTuple newtuple = ((bool) 0);

Hm, did you re-run configure after 7a0574b5?  If you didn't, it would
have gone through the not-stdbool.h path in c.h, which might account
for this.  It's a good catch though, even if by accident :-)

			regards, tom lane

  5. Re: [PATCH] gcc warning 'expression which evaluates to zero treated as a null pointer'

    didier <did447@gmail.com> — 2019-11-14T12:07:54Z

    Hi,

On Wed, Nov 13, 2019 at 10:01 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> didier <did447@gmail.com> writes:
> > clang -E output before 7a0574b5
> > HeapTuple newtuple = 0;
> > with 7a0574b5
> > HeapTuple newtuple = ((bool) 0);
>
> Hm, did you re-run configure after 7a0574b5?  If you didn't, it would
> have gone through the not-stdbool.h path in c.h, which might account
> for this.  It's a good catch though, even if by accident :-)
Yes, that's it. I should have known better, it's no the first time I
made this mistake,
thanks.

Didier