> It's undefined behavior, but what exactly you think will happen if that
> occurs? The result will still be an int32_t which is either in range or not,
> which can happen without invoking any undefined behavior and which we need to
> catch.
>
> So what exactly is this supposed to achieve?
Undefined behavior means that arbitrarily bad things can happen. [This blob
post](https://blob.llvm.org/2011/05/what-every-c-programmer-should-know.html)
is a good introduction.
One alternative is to have `configure` check that the compiler supports
`-fwrapv`, which makes integer overflow well-defined, and error out if the
compiler does not support it. This is a completely legitimate choice to make ―
the OCaml runtime does it ― but it does mean that RPM will no longer be a
standards-conforming C program. Both GCC and Clang support `-fwrapv`, so it
should not limit our portability too much. That said, while I support passing
`-fwrapv` where available, I still believe that integer overflow should be
avoided where possible, mostly because it makes it harder for fuzzers to find
unintended integer overflows. In C and C++, unintended integer overflows are a
common cause of memory corruption.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1502#issuecomment-762079672
_______________________________________________
Rpm-maint mailing list
[email protected]
http://lists.rpm.org/mailman/listinfo/rpm-maint
