[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: deviations tagging


  • To: Roberto Bagnara <roberto.bagnara@xxxxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Fri, 17 Jun 2022 09:18:09 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dlv0S5VbOeBfXGHK2ij+Hzs08t4PaPihQnrVg0t8ess=; b=Q7LNQ4aIpu52fkiEyBrn83Mjy8dU0oZRMDieSTUJ5OR5c8Vw6s/nBNJdHVLBsqpexfbeInXHF13SfonfEx934tKz+jbB0Y1cKnAFOBIF907P0G1OUkA381xMoWOec0QWDVftNVk+iuiJoB6Esrpc5WA/sT7mHj6AYWNqoXvvMeIR5DuvHjV4Q3W5W9jVcOhiWhlS5NpZxxC92OKl6X4BZn0vgpazpVnNFcB+yOgGzZxrJ33+XmIop9szPc+9xMiLuLfi2pudHTBpCxEo4QRSdbhFWh0VsMMx+6jDit6pKxUrIhtxfAJNxBZOAkBaoGsw3FbIKnQi/zppbDX4p2R3QA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lJ3QU5v83VXgo6aD2yw5hqITt5U1rNsuHApvrvaBbDyhEr4ojbShLmwkqzMJVIL1ddQ6d5ATixeB2b1zcL83Q0SeB9bJK1B6Ak05abfd0sIJ6yTUYuAS2GsbZSFLX2tg4TzF3wsraZzNUhaDGXrOKJII2KaesZW0IhLedO+gTEokKjnsrWPfsgWtTXSd6CYDzGDEIgpJNg21ub9Hrx+x05CuhwuxjWeKkyd129cpLZ2AwWU7Mq8PmO+oxASyybq0r+eUaNgFc94TlNymBv+3lGjhp7QB+G5nfW6+4WXOGsx25UK4l/sOONeqfS2xDyA0P/UAw2XHD7SeY/tjiNrrvg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>, fusa-sig@xxxxxxxxxxxxxxxxxxxx, stefanos@xxxxxxxxxx, jbeulich@xxxxxxxx, andrew.cooper3@xxxxxxxxxx, julien@xxxxxxx, Bertrand.Marquis@xxxxxxx, Artem_Mygaiev@xxxxxxxx
  • Delivery-date: Fri, 17 Jun 2022 15:01:57 +0000
  • Ironport-data: A9a23:zLUujqKhZUctIAvxFE+RIpQlxSXFcZb7ZxGr2PjKsXjdYENS0zxRn TZMXGHVO/zYMzGgLdB0PNvj/U9Tv8KHmIJmSgZlqX01Q3x08seUXt7xwmUcns+xwm8vaGo9s q3yv/GZdJhcokf0/0vrav67xZVF/fngqoDUUYYoAQgsA14+IMsdoUg7wbRh3Nc22YTR7z6l4 rseneWOYDdJ5BYsWo4kw/rrRMRH5amaVJsw5zTSVNgT1LPsvyB94KE3fMldG0DQUIhMdtNWc s6YpF2PEsE1yD92Yj+tuu6TnkTn2dc+NyDW4pZdc/DKbhSvOkXee0v0XRYRQR4/ttmHozx+4 OxKqpmPSzUqAvH3l74SWCtTCCpbH5QTrdcrIVDn2SCS52vvViK2htBRVgQxN4Be/ftrC2ZT8 /BeMCoKch2Im+OxxvS8V/VogcMgasLsOevzuFk5lW2fUalgH86FH/+iCdxwhV/cguhUGvnTf YwBYCdHZxXceRxffFwQDfrSmc/32iOjLmMJ8Tp5o4Iz33LKix5L94LNG4WLIvexY85KkWGH8 zeuE2PRR0ty2Mak4SCC+H+2muiJlyr0XosIHZWy6/FxjVucgGcUDXU+Tke2r/C/jQilR9tVJ kgQ+ywvhbgz8E2tXp/2WBjQiHCZpRdZQNtfO+k78x2WjLrZ5R6DAWoJRSIHb8Yp3OctWTEk3 1mOhPv5BDhutq3TQnWYnp+Wpz6vPSkeLUcZeDQJCwAC5rHLopw3jx/JZsZuFuiylNKdMRv92 SyQpS4ywZAal9cW1r6T9ErCxTmro/DhZxQp6wDge3Oq5wJ0eqaof4Wtr1Pc6J59wJ2xS1CAu D0BhJKY5eVXV5WVznTRGqMKAa2j4OuDPHvEm1lzEpI99jOrvXm+YYRX5zI4L0BsWioZRQLUj IbokVs5zPdu0LGCN8ebv6rZ5xwW8JXd
  • Ironport-hdrordr: A9a23:tMTrnamyQoKhO8Mj1KBQD1UhqaDpDfO+imdD5ihNYBxZY6Wkfp +V8cjzhCWftN9OYhodcLC7V5Voj0mskKKdxbNhRYtKOzOWw1dATbsSlLcKpgeNJ8SQzI5gPM tbAstD4ZjLfCJHZKXBkXaF+rQbsb66GcmT7I+xrkuFDzsaDZ2Ihz0JdjpzeXcGIDWua6BJdq Z1saF81kedkDksH42GL0hAe9KGi8zAlZrgbxJDLxk76DOWhTftzLLhCRCX0joXTjsKmN4ZgC P4uj28wp/mn+Cwyxfa2WOWx5NKmOH5wt8GIMCXkMAaJhjllw7tToV8XL+puiwzvYiUmR4Xue iJhy1lE9V46nvXcG3wiRzx2zP42DJr0HPmwU/wuwqWneXJABYBT+ZRj4NQdRXUr2A6ustn7a 5N12WF87JKEBLphk3Glpf1fiAvsnDxjWspkOYVgXAae5AZcqVtoYsW+14QOIscHRj99JssHI BVfY3hDc5tABKnhk3izylSKITGZAVxIv7GeDlOhiWt6UkZoJgjpHFohvD2nR87hecAotd/lq H5259T5cBzp/8tHNxA7dg6MLuK40z2MGXx2TGpUCLa/J9uAQO/l7fHpJMI2cqNRLskiLMPpb WpaiIriYd1QTOlNfGz
  • List-id: This is a discussion list for members of the Xen Project FuSa SIG <fusa-sig.lists.xenproject.org>

On Thu, Jun 16, 2022 at 02:05:24PM +0200, Roberto Bagnara wrote:
> On 6/15/22 09:19, Roger Pau Monné wrote:
> > On Tue, Jun 14, 2022 at 03:47:12PM -0700, Stefano Stabellini wrote:
> > > Hi all,
> > > 
> > > Roberto was suggesting to use the following different categories for
> > > tagging deviations. We could pick any "TAG" we like for the in-code
> > > comments (or other tagging systems).
> > > 
> > > I am also CCing the MISRA C team to give them early visibility on this.
> > > Feel free to provide early feedback if you have any. The plan is to
> > > discuss it further during the next fusa-sig call and come up with a more
> > > detailed proposal (including the actual tags, how to use them and more)
> > > for xen-devel next.
> > > 
> > > Cheers,
> > > 
> > > Stefano
> > > 
> > > 
> > > 
> > > adopted
> > > 
> > >     The report should be considered originated by adopted code without any
> > >     contribution of native code to the report.
> > > 
> > > safe
> > > 
> > >     The report is correct but the specific behavior is safe under every
> > >     aspect assumed to be covered by the guideline.
> > > 
> > > relied
> > > 
> > >     The report is correct but the rule concerns exclusively "developer
> > >     confusion" or readability matters that are not relevant for adopted 
> > > code,
> > >     which is assumed to work as is and it is not meant to be read, 
> > > reviewed
> > >     or modified by human programmers.  To be used for adopted code only.
> > > 
> > > false-positive
> > > 
> > >     In the opinion of the developer the violation report is not correct
> > >     and the problem has been notified to the tool provider.
> > >     To be used only for violation reports.
> > 
> > Do we want to tag false positives?  There's no benefit at all from our
> > code base tagging false positives, I think those should get fixed in
> > the checker tool, or otherwise marked as false positives somewhere
> > else (ie: in the tool itself).
> 
> A false positive is a "definite violation" report issued by a tool which
> turns out not to be real.  (Note that a "possible violation" report,
> sometimes called a "caution" or an "orange", cannot be a false positive
> because it is not a positive: not all tools make this distinction.)
> 
> False positives will be reported, by all tools.  It is not a simple matter
> of the tool being sound or defective: the MISRA coding standards are human
> artifacts with ambiguities and defects.  Issues  of the form "is this a 
> violation?"
> can be in the agenda of the MISRA working groups for years before a final
> decision is made.  During this period, some tools will implement one
> interpretation and other tools will implement a different interpretation.
> (If this surprises you, there are known defects of the C standard that,
> after 20+ years, still nobody is sure how to solve.)
> 
> So, a false positive might sit there for ages, and the benefit for your
> code base in tagging it is that you need not reanalyze it over and
> over again.

Right, we already carry bodges for compilers, so carrying those for
checkers seems inevitable if we plan to use them.

I guess it also depends on how obvious a false-positive is from a
human PoV, and how many of them do we need to tag.  I would really
like to avoid having files plagued with tags to placate
false-positives from the possibly different set of checker tools that
we support, specially if those false-positives are trivial to triage
for a human.

> > > compliant
> > > 
> > >     The developer can prove that the possible non-compliance shown by
> > >     caution report cannot happen in any situation and can motivate such
> > >     claim.  To be used only for caution reports.
> > > 
> > > false-negative
> > > 
> > >     The developer has found a non-compliance not shown by the tool and the
> > >     problem has been notified to the tool provider.
> > 
> > I'm also not sure tagging false-negatives is helpful either, specially
> > if we want to consider this tag system is not bound to any specific
> > tool.  What could be a false negative to a specific checker tool might
> > not be to another, and hence the tag would cause confusion.  False
> > negatives should be tagged like any other violation, ignoring the fact
> > a specific checker tool hasn't been able to spot it.
> 
> > Also I think the usage of 'report' in the descriptions is confusing.
> > AFAICT this is supposed to mean tags are added in reaction to reports
> > by checker tools, but what about deviations that are find by humans,
> > there's no 'report' in that case likely to refer to.  The language
> > seem to be focused against a tags being a reaction to a report from
> > checker tools.
> 
> I am not sure what you mean by "deviation that are found by humans".
> I guess you mean "violations that are found by humans."
> This is indeed rare, because humans are not very good at spotting
> MISRA violations, but once they do, tagging the occurrence is helpful
> during the period in which you and the tool vendor (and maybe the
> MISRA C working group if there is no consensus on whether there
> is a violation there or not) decide what to do about it.

My main concern is why non-compliances not found by a checker tool
needs to be tagged in a specific way (ie: false-negative), IMO they
should just be tagged using the same tags as if the non-compliance was
found by a checker tool.

Anyone interested in false-negatives from a specific checker tool
should be able to obtain them by cross-checking the tags in the code
with the report from the checker tool, and any tags in the source not
matching a checker report would be a false-negative.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.