Re: casting operand to proper type in BlockIdGetBlockNumber - Mailing list pgsql-hackers

From Tom Lane
Subject Re: casting operand to proper type in BlockIdGetBlockNumber
Date
Msg-id 3349756.1646339511@sss.pgh.pa.us
Whole thread Raw
In response to Re: casting operand to proper type in BlockIdGetBlockNumber  (Andres Freund <andres@anarazel.de>)
Responses Re: casting operand to proper type in BlockIdGetBlockNumber  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2022-03-03 14:00:14 -0500, Tom Lane wrote:
>> I'm not sure whether to back-patch --- looking through the
>> git logs, it seems we've back-patched some fixes like these
>> and not others.  Thoughts?

> It'd be easier to run a BF animal if we fixed it everywhere.

Fair enough, will BP.

>> In any case, if we're going to take this seriously it seems like we need a
>> buildfarm machine or two testing this option.

> For the buildfarm, I could enable it on flaviventris? That runs an
> experimental gcc, without optimization (whereas serinus runs with
> optimization). Which seems reasonable to combine with sanitizers?

Dunno.  I already found out that my Mac laptop (w/ clang 13) detects
the numeric.c problem but not any of the other ones.  The messages
on RHEL8 cite where the system headers declare memcmp and friends
with "attribute nonnull", so I'm betting that Apple's headers lack
that annotation.

I also tried adding the various -m switches shown in Zhihong's
CFLAGS setting, but that still didn't repro the Alma warning
for me.

So it definitely seems like it's *real* system dependent which of
these warnings you get :-(.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: [Proposal] Global temporary tables
Next
From: Robert Haas
Date:
Subject: Re: [Proposal] Global temporary tables