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:19:02 +0200	[thread overview]
Message-ID: <d6ab6509-9969-4f36-96fe-b6ce6bc74b73@axis.com> (raw)
In-Reply-To: <b37c26-154a-2db9-4944-26a8aa8af7af@inria.fr>

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.


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:19 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 [this message]
2023-10-11 13:46           ` Julia Lawall
2023-10-11 13:57             ` Anton Eliasson

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=d6ab6509-9969-4f36-96fe-b6ce6bc74b73@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