Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior
Ranier Vilela <ranier.vf@gmail.com>
From: Ranier Vilela <ranier.vf@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Peter Geoghegan <pg@bowt.ie>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Alvaro Herrera <alvherre@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Noah Misch <noah@leadboat.com>
Date: 2020-08-31T20:35:14Z
Lists: pgsql-hackers
Em seg., 31 de ago. de 2020 às 17:05, Andres Freund <andres@anarazel.de> escreveu: > 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. > No problem. If intentional, the code at TransactionIdPrecedes, already knows that overflow can occur and trusts that the compiler will save it. Ranier Vilela
Commits
-
Avoid memcpy() with a NULL source pointer and count == 0
- f0ff52f25cb9 12.6 landed
- 677f74e5bb83 14.0 landed
- 5a1d1b9540a4 13.2 landed
- 49aaabdf8d0b 11.11 landed
-
Avoid calling memcpy() with a NULL source pointer and count == 0.
- 13bba02271dc 9.6.0 cited