Re: Fix runtime errors from -fsanitize=undefined

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix runtime errors from -fsanitize=undefined
Date: 2019-07-05 17:10:44
Message-ID: 29322.1562346644@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> On 2019-07-05 01:33, Noah Misch wrote:
>> I just saw this proposal. The undefined behavior in question is strictly
>> academic. These changes do remove the need for new users to discover
>> -fno-sanitize=nonnull-attribute, but they make the code longer and no clearer.
>> Given the variety of code this touches, I expect future commits will
>> reintroduce the complained-of usage patterns, prompting yet more commits to
>> restore the invariant achieved here. Hence, I'm -0 for this change.

> This sanitizer has found real problems in the past. By removing these
> trivial issues we can then set up a build farm animal or similar to
> automatically check for any new issues.

I think Noah's point is just that we can do that with the addition of
-fno-sanitize=nonnull-attribute. I agree with him that it's very
unclear why we should bother to make the code clean against that
specific subset of warnings.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2019-07-05 17:14:33 Re: SHOW CREATE
Previous Message Tom Lane 2019-07-05 17:06:20 Re: mcvstats serialization code is still shy of a load