I’d really like to *enable as much warnings* as possible to let the build tools *catch as much errors as possible*, and having to adapt the code to work with this is in my opinion worth the effort.
This is not just a question of whether we want to spend the one-time effort to adapt the code. It will be a constant readability issue going forward. Almost no project out there writes shifts like that and almost no programmer is used to reading them like that. I agree that automated sanitizer coverage is a very good thing, but it is not the only thing that matters. If a sanitizer tool forces us two rewrite code in a way that creates serious friction for day-to-day development, then maybe we need to wait until the authors of that tool add options to make it less aggressive in that regard. GCC has already recognized the insanity of reporting that construct as an error every time and thus given us the -Wshift-overflow=1 / -Wshift-overflow=2 distinction, so I hope the UBSAN guys may eventually get there as well.
For now, I think we should deactivate the whole shift test (I'm not an UBSAN expert but from the documentation it sounds like -fno-sanitize=shift-base should work), and then we'll still get the vast majority of coverage without imposing excessive hoops to jump through onto developers.