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

From Andres Freund
Subject Re: casting operand to proper type in BlockIdGetBlockNumber
Date
Msg-id 20220303172937.4cvvdvtxjqvmduxv@alap3.anarazel.de
Whole thread Raw
In response to Re: casting operand to proper type in BlockIdGetBlockNumber  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: casting operand to proper type in BlockIdGetBlockNumber
List pgsql-hackers
Hi,

On 2022-03-03 12:13:40 -0500, Tom Lane wrote:
> Zhihong Yu <zyu@yugabyte.com> writes:
> > On Thu, Mar 3, 2022 at 8:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Oh, I misread this as a compile-time warning, but it must be from ASAN.
> >> Was the test case one of your own, or just our normal regression tests?
> 
> > The Jenkins test is ported from contrib/postgres_fdw/sql/postgres_fdw.sql -
> > so theoretically PG would see the same error for clang12 on Alma.
> 
> Hmph.  I tried enabling -fsanitize=undefined here, and I get some
> complaints about passing null pointers to memcmp and the like, but
> nothing about this shift (tested with clang 12.0.1 on RHEL8 as well
> as clang 13.0.0 on Fedora 35).

We should fix these passing-null-pointer cases...


> What compiler switches are being used exactly?

FWIW, I've successfully used:
-Og -fsanitize=alignment,undefined -fno-sanitize=nonnull-attribute -fno-sanitize=float-cast-overflow
-fno-sanitize-recover=all

Need to manually add -ldl, because -fsanitize breaks our dl test (it uses
dlopen, but not dlsym). Was planning to submit a fix for that...

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Zhihong Yu
Date:
Subject: Re: casting operand to proper type in BlockIdGetBlockNumber
Next
From: Stephen Frost
Date:
Subject: Re: Proposal: Support custom authentication methods using hooks