Horton

Re: casting operand to proper type in BlockIdGetBlockNumber

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Zhihong Yu <zyu@yugabyte.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2022-03-03T19:00:14Z
Lists: pgsql-hackers

Attachments

I wrote:
> Andres Freund <andres@anarazel.de> writes:
>> We should fix these passing-null-pointer cases...

> Yeah, working on that now.

The attached is enough to get through check-world with
"-fsanitize=undefined" using RHEL8's clang 12.0.1.
Most of it is the same old null-pointer-with-zero-count
business, but the change in numeric.c is a different
issue: "ln(-1.0)" ends up computing log10(0), which
produces -Inf, and then tries to assign that to an integer.
We don't actually care about the garbage result in that case,
so it's only a sanitizer complaint not a live bug.

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?

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

			regards, tom lane

Commits

  1. Tighten overflow checks in tidin().

  2. Remove some pointless code in block.h.

  3. Fix bogus casting in BlockIdGetBlockNumber().

  4. Clean up assorted failures under clang's -fsanitize=undefined checks.