Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Peter Geoghegan <pg@bowt.ie>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Ranier Vilela <ranier.vf@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Noah Misch <noah@leadboat.com>
Date: 2020-08-31T20:05:21Z
Lists: pgsql-hackers
Hi,

On 2020-08-31 12:38:51 -0700, Peter Geoghegan wrote:
> On Mon, Aug 31, 2020 at 11:42 AM Andres Freund <andres@anarazel.de> wrote:
> > Unsigned integer overflow is well defined in the standard. So I don't understand what this is purporting to warn about.
> 
> Presumably it's simply warning that the value -4294901760 (i.e. the
> result of 3 - 4294901763) cannot be faithfully represented as an
> unsigned int. This is true, of course. It's just not relevant.
> 
> I'm pretty sure that UBSan does not actually state that this is
> undefined behavior. At least Ranier's sample output didn't seem to
> indicate it.

Well, my point is that there's no point in discussing unsigned integer
overflow, since it's precisely specified. And hence I don't understand
what we're discussing in this sub-thread.

https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html says:

> -fsanitize=unsigned-integer-overflow: Unsigned integer overflow, where
> the result of an unsigned integer computation cannot be represented in
> its type. Unlike signed integer overflow, this is not undefined
> behavior, but it is often unintentional. This sanitizer does not check
> for lossy implicit conversions performed before such a computation
> (see -fsanitize=implicit-conversion).

So it seems Rainier needs to turn this test off, because it actually is
intentional.

Greetings,

Andres Freund



Commits

  1. Avoid memcpy() with a NULL source pointer and count == 0

  2. Avoid calling memcpy() with a NULL source pointer and count == 0.