Let the compiler do the bounds checking

> UndefinedBehaviorSanitizer’s runtime is meant for testing purposes and its usage in production environment should be carefully considered from security perspective as it may compromise the security of the resulting executable. For security-sensitive applications consider using Minimal Runtime or trap mode for all checks.
(https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.ht...)

so it sounds like the "-fsanitize=bounds -fsanitize-trap" combination suggested above should be okay, assuming GCC is similar enough to Clang, and assuming you can interpret the documentation's vague "consider" as a genuine assurance about security.

You still need to be careful about -fsanitize=bounds by itself, and about all the other sanitizers:

> AddressSanitizer is a bug detection tool and its runtime is not meant to be linked against production executables. While it may be useful for testing, AddressSanitizer’s runtime was not developed with security-sensitive constraints in mind and may compromise the security of the resulting executable.
(https://clang.llvm.org/docs/AddressSanitizer.html#securit...)

with the same wording for ThreadSanitizer, MemorySanitizer, LeakSanitizer. The other sanitizers don't document security considerations at all (which presumably doesn't mean there's nothing to consider, just they're not going to help you with that considering).

The sanitizers variously make binaries larger and execution time longer as well. Compiling unit tests with the sanitizers makes more sense, and is a great way to find bugs. A code coverage tool will then identify lines which are not covered by tests. Many code bases are tested in precisely this fashion.

The problem with rsync is more likely a case of "your patch is welcome." If more of us pitched in and helped implement such testing, the code we rely on would be a lot safer.