https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97185
--- Comment #3 from Siddhesh Poyarekar <siddhesh at gcc dot gnu.org> --- (In reply to Martin Sebor from comment #2) > There's a heuristic for ranges of allocation sizes to exclude zero > (size_range_flags) that comes into play here. The actual range isn't > "impossible" in the sense it's necessarily invalid. It just means the > string function call is either a no-op or out of bounds, and so can be > eliminated as an optimization. With the optimization consistently > implemented the warning will also go away (eliminating the calls will > prevent sanitizers from detecting the out of bounds ones, so that might be a > consideration). Ahh I see it now, I had missed that it was an 'int'. ISTM that a better idea would be to *not* optimize away memcpy and memmove in this case, not the other way around. > > In general, a low > high range denoted an anti-range before Ranger was > introduced (i.e., ~[high, low]). With Ranger it's the corresponding union > of two ranges. Some of the cruft for dealing with anti-ranges is still > around, such as in get_size_range() in pointer-query.cc. The code should be > migrated to the irange class and the representation probably also updated to > print something more sensible (e.g., the union [MIN, high) U (low, MAX]; we > talked about introducing a pretty-printer % directive for ranges to make the > format consistent across all diagnostics). That makes sense, thanks.
