https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119104
--- Comment #4 from Alejandro Colomar <alx at kernel dot org> --- (In reply to Jakub Jelinek from comment #3) > The analyzer will be hopefully improved for GCC 16, there was just a minimal > support added so that the analyzer tests didn't regress. > The normal -Wnonnull warning actually uses range information already, so it > the range suggests that the size can't be zero and NULL is passed, there is > a warning emitted. Then, I think memcpy(3) et al. should not use this new attribute until it's stable and has no important regressions, such as this one. It will be fine to use the new attribute once it proves to be safe. > As for actual optimizations, there is a patch in the work to use the range > information, see > https://gcc.gnu.org/pipermail/gcc-patches/2025-March/676805.html > And lastly, far more important than warnings is the runtime sanitization > which is a reliable way to find (certain kinds) of UB in programs and that > handles this attribute and the builtins correctly, checks at runtime > actually that if the corresponding size argument is non-zero and the pointer > is NULL that there is UB that should be diagnosed. Sanitization is a safety net when you have failed to catch the bugs with static analysis. We should aim to catch these bugs at compile time (we were already doing so until now). This is a regression. I have several projects that run the -fanalyzer but do not run sanitizers. > (In reply to Alejandro Colomar from comment #2) > > I've been trying to convince Joseph, Aaron, and the C Committee that it was > > a terrible mistake to allow a null pointer here, precisely for this worry, > > and it seems my worries were correct. > > I strongly disagree with this, I think the change was highly desirable. I agree with wanting to not want to trigger UB within memcpy(3). But I don't think the approach taken was the right one. I think it should have been fixed in implementations first, and then --when we know nothing has regressed--, standardize it.
