> On 27 Sep 2023, at 09:35, Bertrand Marquis <bertrand.marq...@arm.com> wrote: > > Hi Jan, > >> On 27 Sep 2023, at 10:23, Jan Beulich <jbeul...@suse.com> wrote: >> >> On 27.09.2023 10:14, Bertrand Marquis wrote: >>>> On 27 Sep 2023, at 09:53, Nicola Vetrini <nicola.vetr...@bugseng.com> >>>> wrote: >>>> My opinion is that it's far easier for this to be an eclair configuration >>>> (which has the >>>> advantage not to depend on the exact definition of unreachable) and then >>>> perhaps a comment >>>> above it explaining the situation. >>> >>> I agree here and it is easier to make an overall exception where we list >>> the cases >>> where this is acceptable (ie all flavors of unreacheable) and document that >>> eclair >>> was configured using "xxxx" to handle this. >> >> What about cppcheck then, for example? > > Good point we should check if cppcheck or coverity can do such things. > @Luca: any idea ?
So, for cppcheck I don’t think we have such granularity, the only thing we can do are suppress all violations for a file, suppress some violations for a file or suppress globally all violations regarding certain rules. For coverity, I’ve found the way to remove files (translation units) from the report, but I didn’t find anything about how to specify some patterns to be excluded. For now I can only exclude entire files or I can exclude rules globally. I will try to get some support from Synopsys to see if there is any way to specify some exclusion pattern for specific rules. Anyway I’ve run Coverity and for the 2.1 it is finding 14 violations but none of them are about __builtin_unreachable(). I’ve also run Cppcheck and it is not complaining, not that I was looking for it to be a benchmark in any case! So I guess Eclair is more strict on the checks and needs to have a proper configuration that can’t be generalised for all the tools. Cheers, Luca
