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

Re: Proposal for deviations in static analyser findings


  • To: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 19 Oct 2022 10:00:14 +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=zG5oUj1mt+uZIvQd9jtbBI3e4TyhhC7SRnv9n6nV0ds=; b=lUkfapLauY2awnMg9eb9GSuWPPXFf7b1oybsq4gOGTNfZCPuL9WbcwlycuZ4zMHjhbhpbMdg+ddZNSJ1EOfDj2t9gyTyVfq/eeClUjem0P3mkxu3asF30Rm5An1eydiIDTJejVVdSXQnra/3df0uo1vdByGAiQzxWGNV+JGuBWfGbctTHL/mh2AvxpMGmV9uvsVR9s6EyhR14NCdm7ij6ZMJrGSH9q1X0tERHPF+fGzkVJny8dtnn+SdIgUuNtJwrNPurgc4JfbTmB7B5UWXD9JbieLRNY2pS/e1eR6A9fwWG3nNiqIt6ssFbxseAHDF97SE3hAZZekm2sdcwpM/TA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xzgs0hcvm3N/IvxKRHtpnS8qOEbM+J9Z51t+HXUcjm3oGdmfmRoOxPANco7K2Wz3z3y07bBrfvTlw6KVtGZ+5GYZ9NiVk1D7vk9n08XNKQtHRaTiLeyo52pH8IqxkBz5W42EE0UHC1BzgWR8Q1o593oxf/G74csedId+eaRXp09MVRrdYcUWnczi6LrVqpiO8bvIUsnGPKoqFN/KDDY5ijdW4lA4ZdK0P8Ame31/YLDsaXvMk7g304uyRYMi6A6i92tFd/S6RNqCq73imAiVgctJ7O6RuAIvZ4QccUTWyafWqXGPedKkUKLkh3CsgEkT5cI2PlwRjMwrMgsotB1bEA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Luca Fancellu <Luca.Fancellu@xxxxxxx>, Wei Chen <Wei.Chen@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 19 Oct 2022 08:00:26 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 19.10.2022 09:52, Bertrand Marquis wrote:
>> On 19 Oct 2022, at 07:38, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>> On 18.10.2022 18:11, Bertrand Marquis wrote:
>>>> On 18 Oct 2022, at 16:29, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>>> On 18.10.2022 17:17, Luca Fancellu wrote:
>>>>>> On 13 Oct 2022, at 12:34, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>>>>> On 13.10.2022 12:11, Luca Fancellu wrote:
>>>>>>> After the analysis, the source code will return as the original (with 
>>>>>>> the SAF-* tag).
>>>>>>
>>>>>> While you mention something similar also as step 3 in the original 
>>>>>> document
>>>>>> near the top, I'm afraid I don't understand what this "return as the 
>>>>>> original"
>>>>>> means. If you want to run the tool on an altered (comments modified) 
>>>>>> source
>>>>>> tree, what I'd expect you to do is clone the sources into a throw-away 
>>>>>> tree,
>>>>>> massage the comments, run the tool, and delete the massaged tree.
>>>>>>>>> if the object doesn't have a key-value, then the corresponding in-code
>>>>>>>>> comment won't be translated.
>>>>>>>>
>>>>>>>> Iirc at least Coverity ignores certain instances of what it might 
>>>>>>>> consider
>>>>>>>> violations (fall-through in switch() statements in particular) in case
>>>>>>>> _any_ comment is present. Therefore may I suggest that such comments be
>>>>>>>> deleted (really: replaced by a blank line, to maintain correct line
>>>>>>>> numbering) if there's no matching key-value pair?
>>>>>>>
>>>>>>> Yes the line won’t be altered if there is no match. This to ensure the 
>>>>>>> correct line
>>>>>>> numbering is not affected.
>>>>>>
>>>>>> "won't be altered" is the opposite of what I've been asking to consider:
>>>>>> Observing that comments _regardless_ of their contents may silence 
>>>>>> findings,
>>>>>> the suggestion is to remove comments (leaving a blank line) when there's 
>>>>>> no
>>>>>> entry for the targeted tool in the table entry.
>>>>>
>>>>> Why? The tag comment won’t do anything, it would act as a blank line from 
>>>>> the analyser
>>>>> perspective.
>>>>
>>>> The _tag_ won't do anything, but as said any _comment_ may have an effect.
>>>
>>> I am not sure I follow this one but in any case we can choose to anyway 
>>> substitute the tag with something like /* Not applicable */.
>>
>> That's still a comment, which hence may still silence a tool:
>>
>>    switch ( x )
>>    {
>>    case a:
>>        ...
>>        /* SAF-<N>-safe */
>>    case b:
>>        ...
>>        break;
>>    }
>>
>> is no different from
>>
>>    switch ( x )
>>    {
>>    case a:
>>        ...
>>        /* fall-through */
>>    case b:
>>        ...
>>        break;
>>    }
>>
>> nor
>>
>>    switch ( x )
>>    {
>>    case a:
>>        ...
>>        /* Not applicable */
>>    case b:
>>        ...
>>        break;
>>    }
>>
>> Only
>>
>>    switch ( x )
>>    {
>>    case a:
>>        ...
>>
>>    case b:
>>        ...
>>        break;
>>    }
>>
>> will make e.g. Coverity actually point out the potentially unintended
>> fall through (based on past observations). Whether that behavior is
>> fall-through-specific I don't know. If it indeed is, then maybe my
>> concern is void - in the long run I think we want to use the pseudo-
>> keyword there in all cases anyway.
> 
> We can choose the replacement comment to be something not
> considered by the tools (or even put an empty /* */).
> What we cannot do is remove the line as it would change line numbers.

Right, and hence I did say we want to zap the comment, leaving an empty
line.

> But apart from fallthrough I do not think any comment is considered by
> any tools so this should not be an issue.

Well, we can hope for that of course.

Jan



 


Rackspace

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