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

Re: MISRA C meeting tomorrow, was: MOVING COMMUNITY CALL Call for agenda items for 9 June Community Call @ 1500 UTC


  • To: Roberto Bagnara <roberto.bagnara@xxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 9 Jun 2022 13:32:44 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=baF2ghcrgKF1M0W+kGbc6OboNpQy41SERRxrEystets=; b=lRoyT5US5GbUB73fjylrj1F9W6tJ2ZdsSTCU97gdqCOMmjLASxo6lPU+8RdC16+eiM+qAacjzPIqWMK71saM88tw4K4xNW5mloaMvinjSHcSHl4gXAVaVnfdR6fpMLAFMcWWtnNjxkO3j8VEIt/nDjQBCHEsc//zdrcETPDmAkhRK77/xHRcY/OZ4Iu35FiM8MEhv1RbQ0RerAaNbXShwv+l2zxjpm0hCmmZt2dWoOb+oSPldTi3KGSfOwcj3fge10Gt8CJUEZmRz2iGQ4AkG/2/6XVr6pBXaryk298uJxt9QNEZR42W4VXD2dzVGbm+NIzVPRu4JvSYavldKKEEaQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xhf/eqtqo3fRT8+RIuH8Kb1Jdu1mHSicfmsb8hGqQOQhYpTLSLpZEFyzno45L+JIvwbTdjQb/vXWnD3nWGqWXWE5QiZbNCX78ldbHJq1GzUdCXdBKk5dcXKFkleoddWcVi6lAStFPbCf2LtP9eEk9j/xrPxU/T3xzr/ll2JJx31eJN+Ycs/twTYy76f8/V2/zh/Ta8K2jA8Q2GaiSqnDxmKk5qXcOtPLM4FWLNR/5eND9TMUbI8I3oLGC1qjRGjoj9AhxwL74qP5iBBXs2sMyJ29/b0BySJVzWesHzAgrnmwi1TIKJ5PsuqDALUy/R0Xrd8vT5HOkHhtFTVdI/4mBw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: George Dunlap <George.Dunlap@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, Artem Mygaiev <Artem_Mygaiev@xxxxxxxx>, Andrew.Cooper3@xxxxxxxxxx, julien@xxxxxxx, Bertrand.Marquis@xxxxxxx, fusa-sig@xxxxxxxxxxxxxxxxxxxx, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • Delivery-date: Thu, 09 Jun 2022 11:33:02 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 09.06.2022 13:17, Roberto Bagnara wrote:
> On 09/06/22 09:04, Jan Beulich wrote:
>> On 09.06.2022 03:20, Stefano Stabellini wrote:
>>> Finally, for Rule 13.2, I updated the link to ECLAIR's results. There
>>> are a lot more violations than just 4, but I don't know if they are
>>> valid or false positives.
>>
>> I've picked just the one case in xen/common/efi/ebmalloc.c to check,
>> and it says "possibly". That's because evaluation of function call
>> arguments involves the calling of (in this case two) further
>> functions. If those functions had side effects (which apparently the
>> tool can't figure), there would indeed be a problem.
>>
>> The (Arm based) count of almost 10k violations is clearly a concern.
>> I don't consider it even remotely reasonable to add 10k comments, no
>> matter how brief, to cover all the false positives.
> 
> Again, the MISRA approach is a preventive one.
> If you have reasons you want to write
> 
>     f(g(), h());
> 
> then declare g() and h() as pure (or const, if they are const).
> E.g.:
> 
> #if COMPILER_SUPPORTS_PURE
> #define PURE __attribute__((pure))
> #else
> #define PURE
> #endif
> 
> int g(void) PURE;
> int h(void) PURE;
> 
> It's good documentation, it improves compiler diagnostics,
> and it satisfies Rule 13.2.

But such attributes first of all should be correct. They wouldn't be
in the case I've looked at (involving two __virt_to_maddr() invocations),
as the underlying va_to_par() isn't pure. Still in the normal case the
sequence of calls made is irrelevant to the overall result.

As to improving compiler diagnostics: It has been my experience that
pure and const are largely ignored when used on inline functions. The
compiler rather looks at the inline-expanded code to judge. (But it has
been a couple of years back that I last checked, so things may have
changed since then.)

Jan



 


Rackspace

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