On Tue, Aug 11, 2015 at 4:10 PM, Dan Albert <danalb...@google.com> wrote: >> Would you be opposed to annotations that tell the programmer they have >> UB in their code, but *do not* effect the code generation? > > > Not on our end. This would be great.
I ask because the new nullability attributes do not affect codegen (that I'm aware of), and so they might be a reasonable tradeoff between warning users that they've done something with UB, without triggering aggressive optimizations, if we didn't want to have some sort of flag for this. That being said, the user's code does have UB if it passes in a null pointer for these APIs and relying on the compiler to not optimize that is asking for trouble. Warning them about the UB is very important. Not optimizing on the UB is far less so, IMO. ~Aaron > > On Tue, Aug 11, 2015 at 12:56 PM, Aaron Ballman via cfe-commits > <cfe-commits@lists.llvm.org> wrote: >> >> On Tue, Aug 11, 2015 at 3:32 PM, Joerg Sonnenberger via cfe-commits >> <cfe-commits@lists.llvm.org> wrote: >> > joerg added a comment. >> > >> > No, it doesn't. It tells the compiler that it is free to make such >> > assumptions. Take a step back from the standard. Can you think of any >> > reasonable and efficient implementation of memcpy and friends, which fails >> > for size 0? Adding the annotations (whether here or in string.h) >> > effectively >> > changes the behavior of the program. It is behavior people have been >> > expecting for two decades, even when C90 said something else. This is >> > completely different from the warning annotations. I'm just waiting for >> > some >> > of the bigger projects like PostgreSQL to start getting annoyed enough to >> > introduce sane_memcpy for this. >> > I can't speak for Linux distributions using glibc, but I find this kind >> > of smoking gun completely unacceptable to force unconditionally on >> > everyone. >> >> Would you be opposed to annotations that tell the programmer they have >> UB in their code, but *do not* effect the code generation? >> >> ~Aaron >> _______________________________________________ >> cfe-commits mailing list >> cfe-commits@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > > _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
