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

Re: [PATCH] docs/misra: add exceptions to rules


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 23 Aug 2023 08:42:11 +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=phSsjkXKzy+yW2tsv7VHKyg6GR6ls6gy0kdRJtNmjPk=; b=l6wuSX/nilJ068r5aCZOSsFSyDJZSyKrVH29RKyfwop7GPamZRChNRI1GP9crPTgGNzIG6Gt1TqjOjifSMjrzrAwiF3XvcyJ3Fniiweg7qIN1oYFhH3fYrE8wQXjonGTxftXZ+xEMr8CYI/M72xuqFJDLhwWf/ikTFF1TLDMgykfLpMRPaTVMomTfBw85XzqBQQsIdJN0Wzx/eDF4wM1gq47srH7Ou14NKe8NjmCIHE9VXMzrMKZ3VDNZSg1KRZg1R7gLx/+dXMNMTVg9tqTQ3nty25zVwcj69byV1uhhdwd5Iu+WjXES+Ae3C+j6g3/7hFLxQX4ZiLY00oNra4f6A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=etbpmJ2RT7Q56v+4cLZKTZcyAb/dnDNJ1O3ZY50fOS+Jc7NbSvg2HB5Tt2iOomr9gvgd1ilWTSk/RvN7CmWylYoz6RK6F2FIQGMfM/RjgZu2ly9bORThLkVLbaslQoE5ZPUewaCgQBeIhPiSjhVH6JtlbY8lzSBUH0A4eTH5XoVVfrgaIO+1FVXhHn5IWlKpuWtMvSOln+Fk27Ba7UtZaQy1r/RQdOxoOTsgvVP14ZbkozsafP9DxE2kKJa25ieObK1J8Cr4rZBoZas2p0y0HmD9zWEaRaTzE8vgHlZNeCns8u6Rm9hXA+nCij7vTGR4Fw4tl491ZcLovYW6RQ4MKw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 23 Aug 2023 06:42:25 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 23.08.2023 02:19, Stefano Stabellini wrote:
> On Tue, 22 Aug 2023, Jan Beulich wrote:
>> (re-adding xen-devel@)
>>
>> On 22.08.2023 17:09, Nicola Vetrini wrote:
>>>
>>>>>> +         - Switch with a controlling value incompatible with labeled
>>>>>> +           statements
>>>>>
>>>>> What does this mean?
>>>>
>>>> I am not certain about this one actually. It could be when we have:
>>>>
>>>> switch (var) {
>>>>   case 1:
>>>>       something();
>>>>       break;
>>>>   case 2:
>>>>       something();
>>>>       break;
>>>> }
>>>>
>>>> and var could be 3 in theory?
>>>>
>>>> Nicola, please confirm.
>>>>
>>>>
>>>
>>> This one is about case labels that are statically determined not to be 
>>> reachable (and hence
>>> saying that the code under that label is unreachable is not inaccurate) 
>>> because the
>>> controlling expression of the switch statement can never have such 
>>> value. An example below:
>>>
>>> $ cat p.c
>>> int f(void) {
>>>    char c;
>>>    switch (c) {
>>>      case 260:
>>>        return 260;
>>>      case 4:
>>>        return 4;
>>>    }
>>> }
>>>
>>> $ eclair_env -enable=MC3.R2.1,B.REPORT.TXT -- gcc -c p.c
>>> violation for rule MC3.R2.1: (required) A project shall not contain 
>>> unreachable code. (untagged)
>>> p.c:3.3-3.8: Loc #1 [culprit: `switch' statement has a controlling value 
>>> incompatible with labeled statement]
>>>    switch (c) {
>>>    <~~~~>
>>> p.c:5.14-5.16: Loc #2 [evidence: integer literal is unreachable]
>>>        return 260;
>>>               <~>
>>>
>>> This is also true for things like
>>>
>>> switch(sizeof(int)) {
>>>    case 2:
>>>      ...
>>>    case 4:
>>>      ...
>>> }
>>
>> Ah yes, we certainly have quite a few of those. Not sure how to best
>> describe such for the doc, but what was suggested (still visible at
>> the top) doesn't get this across, I'm afraid,
> 
> What about: "switch with a controlling value statically determined not
> to match one or more case statements"

Sounds okay, assuming this is the only case we want to treat specially.

Jan



 


Rackspace

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