On Wed, Sep 24, 2025 at 08:41:05AM +0200, Martin Uecker wrote:
> Often I am interested in what I need to fix in the source code to avoid
> the trap (because this may not be acceptable, e.g. when controlling some
> hardware or because I want to remove performance impact of having the
> conditional check). So, I like a diagnostic because it ties it back to
> the source code and existing tools can handle this nicely. For example,
> consider this example:
>
> maybe(int) safe_divide(int a, int b)
> {
> if (b == 0)
> return maybe_nothing(int);
>
> return maybe_just(int, a / b);
> }
>
> I would expect that compiling with
>
> -fsanitize=undefined -fsanitize-trap=all -O2
>
> comes up clean because I tested for zero and I expect the later trap to
> be removed by the optimizer. But with the warning it tells me:
>
>
> div.c: In function ‘safe_divide’:
> div.c:13:34: warning: trap generated: "builtin" [-Wtrap]
> 13 | return maybe_just(int, a / b);
> | ^
Note, UBSan intentionally attempts in many cases not to rely on certain
kind of optimizations because they rely on lack of UB in the program and
UBSan is meant to detect programs with UB in it.
So e.g. using VRP info is problematic, in some cases it relies on checks
which are there at runtime and so will happen even in programs with UB,
but just replace return maybe_nothing(int); in your above testcase
with __builtin_unreachable (); and program with UB will happily run into
the division even with zero divisor.
Sometimes we do just leave it to optimizers though, so best checking is
certainly at -O0 -fsanitize=undefined, but with higher levels we should
still maintain some middle ground and not try to optimize UBSan
instrumentation too heavily.
In the division particular case, we just turn it into
if (b == 0) report_or_trap (); x = a / b;
or for signed into
if (b == 0 || (b == -1 && a == INT_MIN)) report_or_trap (); x = a / b;
and so VRP will happily optimize it away.
Jakub
