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

Re: [XEN PATCH][for-4.19 v2 1/1] xen: introduce a deviation for Rule 11.9


  • To: andrew.cooper3@xxxxxxxxxx
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 16 Oct 2023 15:46:26 +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=4YBYUd9zr4aIu1nkPk8WLGBE4ZzQT6DzC+Sv39wG8QY=; b=Rr6q528yd0/qpAIGc/qGZce71Wsp3cPBzXI/UYyqqcJFO+2C4GTIMZQQGw+onV11tqu7WUxFl++CnU5rn92an/fi76eX1tqbQ1LKkB8hfRGVJzYGjJQwIU7SVwPlUokBv7Hxx8G/4GhdZJklK9gXOKUXzR741zMKFFV2lKne2/T8h1ieP3wsjEwCTECFk+WjWyL0SXtBoU+ffmNgGvxWw8z3vvcmQfjY3Emi/m5GCbL/SUXjETRKQ8UyWaSbRT/Fq9GFbLrz/9tpPpOtXKOLlBB9wzUTLTG/4DebH+JmVOEz+oEa/BLHlAxbu724U20pVxzOzzeCwS3dxWJCUulRjg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Bgrk9Z6DEiZ5h9wG3XZwN13PuYV1kOjWEzb5ADFiCVta5zhfDGVB0fXdEPhgxCyIZDUHNO4l/GK1YbIgpZSDgE/Gg9T/ebaS6bKZv6RZaTDBlF57squoKipJbH+/sB2Jl/kHzFLcObjg7zAAZMfloUTbQU8LaxD+x3+MbkJzafzrCvfz1bDP8URISDG95Pb/VDmywdASht0obHOvQQCtR4lRwi5TGsWHQi6HCaOsANcGm+KCeFmvMG5fv0qN3Hoq4egTg2U2duaqnJ0yJW6mV/d/l27CNkCxJyjcSTVnf4KArOedn7tAZIJgPQYDVC9n6o6m8d1t1rYIL/5DXx2a0g==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: sstabellini@xxxxxxxxxx, michal.orzel@xxxxxxx, xenia.ragiadakou@xxxxxxx, ayan.kumar.halder@xxxxxxx, consulting@xxxxxxxxxxx, roger.pau@xxxxxxxxxx, Simone Ballarin <simone.ballarin@xxxxxxxxxxx>, Doug Goldstein <cardoe@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 16 Oct 2023 13:46:34 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 11.10.2023 18:56, andrew.cooper3@xxxxxxxxxx wrote:
> On 11/10/2023 8:46 pm, Nicola Vetrini wrote:
>> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
>> index ee7aed0609d2..1b00e4e3e9b7 100644
>> --- a/docs/misra/deviations.rst
>> +++ b/docs/misra/deviations.rst
>> @@ -199,6 +199,11 @@ Deviations related to MISRA C:2012 Rules:
>>         See automation/eclair_analysis/deviations.ecl for the full 
>> explanation.
>>       - Tagged as `safe` for ECLAIR.
>>  
>> +   * - R11.9
>> +     - __ACCESS_ONCE uses a 0 as a null pointer constant to check if a type 
>> is
>> +       scalar, therefore its usage for this purpose is allowed.
>> +     - Tagged as `deliberate` for ECLAIR.
> 
> Really?
> 
> #define __ACCESS_ONCE(x)
>     (void)(typeof(x))0; /* Scalar typecheck. */
> 
> That's not a pointer.
> 
> If someone were to pass in an x who's type was pointer-to-object, then
> yes it is technically a NULL pointer constant for long enough for the
> build to error out.

Why would it error out? ACCESS_ONCE() on a variable of pointer type is
as okay as one on a variable of (some kind of) integer type. (Sadly the
check as is would even let floating point types pass. At the same time
the check is too strict to allow e.g. single-machine-word struct/union
to also pass.)

Jan



 


Rackspace

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