Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior
От | Andres Freund |
---|---|
Тема | Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior |
Дата | |
Msg-id | 20200831200521.kpu6fhblqxhhds4x@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior
|
Список | 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
В списке pgsql-hackers по дате отправления: