JustinStitt wrote: @melver > Oh nice. If you have that almost done, why do you still want the filterlist? > For the Linux kernel usecase, wouldn't the attribute be preferrable? My > intuition tells me that maintaining a filterlist detached from the code will > cause headaches, esp. during refactors or code moves (and you don't want to > be the one chasing after the breakages).
We need both the filterlist and attribute support because of the agreed upon ideology about how integer overflow is reasoned about in the Linux kernel. Basically, the compromise that was reached involves marking all types as `wrapping` so that the sanitizers won't warn for just any arithmetic. Following this, specific types (like `size_t`) will be marked as `no_wraps` which means the sanitizers will do their thing. The best way to "mark all types" is with filterlists; and the best way to mark one (or a few) types is with in-source attributes. I know @kees feels strongly that this should be the other way around: Instrument _everything_ by default (which would eliminate the need for filterlist integration entirely) and exclude things from instrumentation with `wraps`. Either way, my patch set implements both `wraps` and `no_wraps` and folks can use whichever they please. Using `wraps`/`no_wraps` will not force users to interact with or use ignorelists at all -- those attributes will simply integrate nicely with ignorelists if supplied. https://github.com/llvm/llvm-project/pull/107332 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
