https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114217
--- Comment #13 from Akihiko Odaki <akihiko.odaki at daynix dot com> ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Akihiko Odaki from comment #11)
> > So there are two constructs invoking UBs but ignored by UBSan: 1)
>
> That is an understatement. UBSan is a best effort which diagnoses some forms
> of undefined behavior. There are tons of undefined behavior UBSan doesn't
> catch,
> most importantly e.g. aliasing violations, but far from limited to just that.
> If a program is diagnostic free with -fsanitize=undefined,address , it
> doesn't mean it is UB free, but the goal is that if there is diagnostic,
> there is a real UB in the program.
Right. I just listed the two relevant constructs and don't intend to say they
are the only case that UBSan doesn't catch.
>
> You are basically asking for the PR80797 fix to be reverted just because you
> aren't willing to fix UB in your code. That is not going to happen, we've
> been diagnosing this for almost 7 years now, I think clang even for 11
> years, it is a real UB and other projects have been able to cope with it.
> By reverting the change new UB in other programs couldn't be discovered.
I'm not asking for reverting PR80797. See f() and f2() I wrote earlier:
u64 f(struct dir_entry *entry)
{
return get_unaligned(&entry->offset);
}
u64 f2(u64 *offset)
{
return get_unaligned(offset);
}
Both f(NULL) and f2(NULL) should be caught and there should be no discrepancy
in behavior for these two functions. However, there is a discrepancy when it
comes to -fsanitize=alignment.
I'm not saying ignoring UB in f() is the only sensible option either. Catching
UBs in both f() and f2() is a logical option.
