https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119429
--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Desmond Rhodes from comment #0) > And according to the standard, `size_t` or `unsigned` numerics > overflow/underflow are well defined. No, according to the standard they're is no such thing as unsigned overflow. The sanitizer is incredibly misleading to label these diagnostics the same way as real undefined behaviour. > However, I believe that assigning `-1` to `size_t` is non-sensical. It's 100% valid C++ with well-defined meaning. It's the all-ones value. > In > addition, I also would like to continue to use `-fsanitize=integer` in my > program development. Therefore, I believe this is both a semantic bug and a > bug for the users of the standard library. The code is correct. If you choose to enable a tool that warns about correct code, you should be prepared to deal with that. > If assigning the `size_t` to the largest possible value is indeed the > intended behavior, please make it explicit by using `std::SIZE_MAX` so that > it does not trigger `UndefinedBehaviorSanitizer`. That wouldn't even compile, SIZE_MAX is a macro and not in namespace std. (size_t)-1 or -1zu would probably silence this bogus diagnostic though.
