The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Anton Eliasson <anton.eliasson@axis.com>
To: Julia Lawall <julia.lawall@inria.fr>
Cc: Nicolas Palix <nicolas.palix@imag.fr>,
	cocci@inria.fr, linux-kernel@vger.kernel.org, kernel@axis.com
Subject: Re: [cocci] [PATCH 2/2] scripts: coccicheck: Separate spatch stdout and stderr
Date: Wed, 11 Oct 2023 15:57:58 +0200	[thread overview]
Message-ID: <d76cafc0-572f-4a5e-b4e0-5baa060a1256@axis.com> (raw)
In-Reply-To: <e695187c-e83-c844-7f70-7bb9d952569@inria.fr>

On 11/10/2023 15.46, Julia Lawall wrote:
>
> On Wed, 11 Oct 2023, Anton Eliasson wrote:
>
>> On 10/10/2023 18.11, Julia Lawall wrote:
>>> On Tue, 10 Oct 2023, Anton Eliasson wrote:
>>>
>>>> On 07/10/2023 21.41, Julia Lawall wrote:
>>>>> On Tue, 3 Oct 2023, Anton Eliasson wrote:
>>>>>
>>>>>> This helps automating coccicheck runs by discarding stderr and only
>>>>>> looking at the output of stdout. In report mode the only remaining
>>>>>> output on stdout is the initial "Please check for false positives"
>>>>>> message followed by each spatch warning found.
>>>>> What is getting dropped is the spatch command lines indicating the
>>>>> semantic patch.  Is this desirable?
>>>>>
>>>>> julia
>>>> It's not ideal but it's the best compromise that I have found. The problem
>>>> I'm
>>>> trying to solve is to be able to diff the output of two coccicheck runs
>>>> and
>>>> notify the developer if any new warnings were introduced. That requires
>>>> the
>>>> output to be stable. spatch is always invoked for each cocci file in the
>>>> same
>>>> order. However, the output from each spatch invocation is not stable as it
>>>> examines each source file in an arbitrary order.
>>>>
>>>> My workaround is to sort the output before diffing. The line-by-line
>>>> sorted
>>>> output only makes sense if the input is one line per warning found and
>>>> that is
>>>> why I try to discard all output except the single line per spatch warning.
>>>> While the terse output doesn't tell which semantic patch file generated
>>>> the
>>>> warning, it does usually contain the offending file, line number and a
>>>> summary
>>>> of the issue.
>>> Why does the command line pose a problem for sorting?
>>>
>>> julia
>> You're right. I was overthinking it. Since the sorted command lines will be
>> common for the two runs they will disappear after diffing.
>>
>> So at this point I don't have any need for this patch. I'll reach out to you
>> again if it turns out to be an issue after we have gotten the continuous
>> integration check in place. Thanks for the feedback and I'm sorry about the
>> noise.
> OK, thanks for the discussion.  I was also thinking about whether it could
> be possible to make the output always come out in the same order, based on
> the name of the analyzed file.  Maybe it is possible.
>
> julia

Yes, that might help to preserve some context. The difference between 
two runs could be presented as a unified diff instead of just lines 
added. That would probably contain the command line invoking the 
semantic patch that caused the warning, unless there are too many 
pre-existent warnings.


Anton

>
>>
>> Anton
>>
>>>> Anton
>>>>>> Signed-off-by: Anton Eliasson <anton.eliasson@axis.com>
>>>>>> ---
>>>>>>     scripts/coccicheck | 4 ++--
>>>>>>     1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/scripts/coccicheck b/scripts/coccicheck
>>>>>> index 95a312730e98..7e7c44125f47 100755
>>>>>> --- a/scripts/coccicheck
>>>>>> +++ b/scripts/coccicheck
>>>>>> @@ -146,8 +146,8 @@ run_cmd_parmap() {
>>>>>>                     echo $@>>$DEBUG_FILE
>>>>>>                     $@ 2>>$DEBUG_FILE
>>>>>>             else
>>>>>> -                echo $@
>>>>>> -                $@ 2>&1
>>>>>> +                echo $@ >&2
>>>>>> +                $@
>>>>>>     	fi
>>>>>>
>>>>>>     	err=$?
>>>>>>
>>>>>> --
>>>>>> 2.30.2
>>>>>>
>>>>>>
>>


      reply	other threads:[~2023-10-11 13:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-03 14:25 [PATCH 0/2] coccicheck bugfix and CI improvement Anton Eliasson
2023-10-03 14:25 ` [PATCH 1/2] scripts: coccicheck: Return error from run_cmd_parmap Anton Eliasson
2023-11-02 21:27   ` [cocci] " Julia Lawall
2023-11-17 16:36     ` Anton Eliasson
2023-10-03 14:25 ` [PATCH 2/2] scripts: coccicheck: Separate spatch stdout and stderr Anton Eliasson
2023-10-07 19:41   ` [cocci] " Julia Lawall
2023-10-10 15:59     ` Anton Eliasson
2023-10-10 16:11       ` Julia Lawall
2023-10-11 13:19         ` Anton Eliasson
2023-10-11 13:46           ` Julia Lawall
2023-10-11 13:57             ` Anton Eliasson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d76cafc0-572f-4a5e-b4e0-5baa060a1256@axis.com \
    --to=anton.eliasson@axis.com \
    --cc=cocci@inria.fr \
    --cc=julia.lawall@inria.fr \
    --cc=kernel@axis.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolas.palix@imag.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox