Hi,
On 2024-06-09 21:57:54 -0400, Tom Lane wrote:
> BTW, while I approve of trying to get rid of our need for -fwrapv,
> I'm quite scared of actually doing it.
I think that's a quite fair concern. One potentially relevant datapoint is
that we actually don't have -fwrapv equivalent on all platforms, and I don't
recall a lot of complaints from windows users. Of course it's quite possible
that they'd never notice...
I think this is a good argument for enabling -ftrapv in development
builds. That gives us at least a *chance* of seeing these issues.
> Whatever cases you may have discovered by running the regression tests will
> be at best the tip of the iceberg. Is there any chance of using static
> analysis to find all the places of concern?
The last time I tried removing -fwrapv both gcc and clang found quite a few
issues. I think I fixed most of those though, so presumably the issue that
remain are ones less easily found by simple static analysis.
I wonder if coverity would find more if we built without -fwrapv.
GCC has -Wstrict-overflow=n, which at least tells us where the compiler
optimizes based on the assumption that there cannot be overflow. It does
generate a bunch of noise, but I think it's almost exclusively due to our
MemSet() macro.
Greetings,
Andres Freund