On 10/24/17 9:01 AM, SF Markus Elfring wrote:
>>> Do you prefer to delegate the proposed software refactoring
>>> only to a corresponding optimiser?
>>
>> yes.
>
> Will any applications around the semantic patch language
> (Coccinelle software) fit also in the preferred tool category?
What do you
On 10/27/17 10:20 AM, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Fri, 27 Oct 2017 18:00:31 +0200
>
> Adjust jump targets so that a bit of exception handling can be better
> reused in an if branch of this function.
What is the benefit brought by this change?
Anyhow, are you seriousl
On 12/12/16 10:15 AM, SF Markus Elfring wrote:
>>> I suggest to check return values immediately after each function call.
>>> An error situation can be detected earlier then and only the required
>>> clean-up functionality will be executed at the end.
>>
>> Which improvement does this bring?
>
> *
On 12/12/16 11:03 AM, SF Markus Elfring wrote:
>> Have you proposed a similar patch that was accepted?
>
> Yes. - It happened a few times.
The question was: have you ever had a patch changing code in the form
{
a = kmalloc(...);
b = kmalloc(...);
if (!a || !b)
On 12/12/16 3:11 PM, SF Markus Elfring wrote:
>>> It is really needed to clarify the corresponding software development
>>> history any further?
>>
>> It is relevant because you are submitting a patch and your changelog
>> implies that it makes the code follow some code structure rule that
>> needs
On 10/12/16 13:48, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sat, 10 Dec 2016 09:29:24 +0100
>
> The kfree() function was called in one case by the
> bttv_input_init() function during error handling
> even if the passed variable contained a null pointer.
kfree() is safe to call on
On 10/12/16 15:10, SF Markus Elfring wrote:
>> Despite that, you have found several instances of similar constructs:
>
> Yes. - Special source code search pattern can point such places out
> for further considerations.
This is one of the things that makes reviewing the patches you submit
quire an
On 12/12/16 00:33, SF Markus Elfring wrote:
>>> I would prefer a safer coding style for the corresponding
>>> exception handling.
>>
>> Can you please point out what is wrong in the current code
>
> Is it useful to reconsider the software situation that another memory
> allocation is attempted whe
Hello,
On 3/13/17 2:40 PM, Arushi Singhal wrote:
> This patch fixes the warnings reported by checkpatch.pl
> for please use a blank line after function/struct/union/enum
> declarations.
I haven't seen this pointed out by others before: starting a commit
message with "This patch..." is redundant (
On 9/22/17 11:46 AM, SF Markus Elfring wrote:
They are both equally uninformative.
>>>
>>> Which identifier would you find appropriate there?
>>
>> error was fine.
>
> How do the different views fit together?
You want to change something. Changing something requires to spend
energy. You ne
10 matches
Mail list logo
