From: Greg Dietsche <greg@farmergreg.com>
To: Julia Lawall <julia@diku.dk>
Cc: Greg Dietsche <greg@farmergreg.com>,
linux-kernel@vger.kernel.org, cocci@diku.dk,
Gilles.Muller@lip6.fr
Subject: Re: [Cocci] Re: [PATCH v2] coccinelle: if (ret) return ret; return ret; semantic patch
Date: Wed, 15 Jun 2011 10:33:08 -0500 [thread overview]
Message-ID: <4DF8D0B4.7020505@gregd.org> (raw)
In-Reply-To: <Pine.LNX.4.64.1106150751390.27735@ask.diku.dk>
On 06/15/2011 12:58 AM, Julia Lawall wrote:
> On Tue, 14 Jun 2011, Greg Dietsche wrote:
>
>>
>>
>> On 06/14/2011 04:24 PM, Greg Dietsche wrote:
>>> On 06/14/2011 12:50 AM, Julia Lawall wrote:
>>>> On Mon, 13 Jun 2011, Greg Dietsche wrote:
>>>>> just curious... i see you usually just write "return ret;" here when
>>>>> posting.
>>>>> I've assumed that's because it will 1) work and 2) is close enough.
>>>>>
>>>>> You'll notice I've been doing:
>>>>> -return ret;
>>>>> +return ret;
>>>>> because it seems to help coccinelle realize that it can get rid of
>>>>> extra line
>>>>> feeds - does this make sense - or should i just be doing a "return ret"?
>>>> I wondered why you were doing that :)
>>>>
>>>> Is the problem that the removed if is being replaced by a blank line? If
>>>> so, that is not intentional. I will look into it. If it doesn't happen
>>>> always, an example where it does happen could be helpful.
>>>>
>>>
>>> Some times it gets it right, so it's not always wrong. For example:
>>>
>>> diff -u -p a/arch/m68k/math-emu/fp_log.c b/arch/m68k/math-emu/fp_log.c
>>> --- a/arch/m68k/math-emu/fp_log.c 2011-06-13 14:06:37.943954469 -0500
>>> +++ b/arch/m68k/math-emu/fp_log.c 2011-06-14 16:07:22.394954040 -0500
>>> @@ -105,9 +105,6 @@ fp_fetoxm1(struct fp_ext *dest, struct f
>>>
>>> fp_monadic_check(dest, src);
>>>
>>> - if (IS_ZERO(dest))
>>> - return dest;
>>> -
>>> return dest;
>>> }
>>>
>>>
>>>
>>> Here's an example where it got it "wrong" - notice how the blank line is
>>> missing the - :
>>>
>>> diff -u -p a/arch/frv/mm/pgalloc.c b/arch/frv/mm/pgalloc.c
>>> --- a/arch/frv/mm/pgalloc.c 2011-06-13 14:06:37.855954391 -0500
>>> +++ b/arch/frv/mm/pgalloc.c 2011-06-14 16:07:16.714954008 -0500
>>> @@ -136,8 +136,6 @@ pgd_t *pgd_alloc(struct mm_struct *mm)
>>> pgd_t *pgd;
>>>
>>> pgd = quicklist_alloc(0, GFP_KERNEL, pgd_ctor);
>>> - if (!pgd)
>>> - return pgd;
>>>
>>> return pgd;
>>> }
>
> OK, but it is going to be hard for Coccinelle to know that, although the
> programmer previously thought that return should be separated from the
> rest of the function by a blank line, that is now no longer the case.
> Perhaps it is due to the fact that there is now only one other line in the
> body of the function, but it seems like an opinion as to how to draw the
> line.
>
OK - I can see how that would be hard for Coccinelle to guess what we
really want in this case.
> So your - return ret; + return ret; is probably the appropriate solution.
> You want to get rid of the whole pattern if (...) return ret; return ret;
> and replace it with just return ret;, which will then be inserted at the
> point of the beginning of the match to the pattern.
ok
> It would be nicer to put the - return ret; + return ret; inside the last
> line of the ( | ). Then only those return ret's are rewritten rather than
> every return ret in the program. It should improver performance and
except that 4 of the 5 ORs are cases where we want to do the -return
ret; + return ret; So I suppose for performance, I should actually add
the +/- to each of the 4 cases that we want cocci to generate a patch for?
thanks,
Greg
> reduce the risk of changing spacing. The other ifs in the ( | ) don't
> need to be followed by return ret. They are just ifs that you want to
> ignore completely.
>
> julia
next prev parent reply other threads:[~2011-06-15 15:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-06 0:26 [PATCH] coccinelle: if(ret)return ret; return ret; semantic patch Greg Dietsche
2011-06-06 4:55 ` Julia Lawall
2011-06-07 15:47 ` Greg Dietsche
2011-06-07 16:56 ` Julia Lawall
2011-06-07 21:54 ` Nicolas Palix
2011-06-07 22:59 ` Greg Dietsche
2011-06-08 7:11 ` Nicolas Palix
2011-06-08 7:24 ` Julia Lawall
2011-06-11 15:37 ` Greg Dietsche
2011-06-11 15:43 ` Julia Lawall
2011-06-06 4:56 ` Julia Lawall
2011-06-13 18:23 ` [PATCH v2] coccinelle: if (ret) return " Greg Dietsche
2011-06-13 18:36 ` Joe Perches
2011-06-13 18:38 ` Julia Lawall
2011-06-13 20:55 ` Greg Dietsche
2011-06-14 5:50 ` Julia Lawall
2011-06-14 21:24 ` Greg Dietsche
2011-06-15 1:15 ` Greg Dietsche
2011-06-15 5:58 ` Julia Lawall
2011-06-15 15:33 ` Greg Dietsche [this message]
2011-06-15 15:34 ` [Cocci] " Julia Lawall
2011-06-15 15:35 ` Julia Lawall
2011-06-15 16:05 ` Greg Dietsche
2011-06-15 1:29 ` [PATCH v3] " Greg Dietsche
2011-06-15 5:50 ` Julia Lawall
2011-06-15 15:50 ` [PATCH v4] " Greg Dietsche
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=4DF8D0B4.7020505@gregd.org \
--to=greg@farmergreg.com \
--cc=Gilles.Muller@lip6.fr \
--cc=cocci@diku.dk \
--cc=julia@diku.dk \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.