Julia Lawall writes:
> On Sat, 2 Jan 2016, SF Markus Elfring wrote:
>
>> >> Move the jump label directly before the desired log statement
>> >> so that the variable "err" will not be checked once more
>> >> after it was determined that a function call failed.
>> >> Use the identifier
Julia Lawall writes:
> On Sat, 2 Jan 2016, SF Markus Elfring wrote:
>
>> >> Move the jump label directly before the desired log statement
>> >> so that the variable "err" will not be checked once more
>> >> after it was determined that a function call failed.
>> >> Use the
On 4 January 2016 at 11:05, Arend van Spriel wrote:
> On 03-01-16 16:18, Rafał Miłecki wrote:
>> On 3 January 2016 at 10:36, Arend van Spriel wrote:
>>> On 02-01-16 12:21, SF Markus Elfring wrote:
> Did you look at the resulting assembly code for different target
> architectures?
On 03-01-16 16:18, Rafał Miłecki wrote:
> On 3 January 2016 at 10:36, Arend van Spriel wrote:
>> On 02-01-16 12:21, SF Markus Elfring wrote:
Did you look at the resulting assembly code for different target
architectures?
>>>
>>> Not yet. - Which execution system variants would you
On 4 January 2016 at 11:05, Arend van Spriel wrote:
> On 03-01-16 16:18, Rafał Miłecki wrote:
>> On 3 January 2016 at 10:36, Arend van Spriel wrote:
>>> On 02-01-16 12:21, SF Markus Elfring wrote:
> Did you look at the resulting assembly code for
On 03-01-16 16:18, Rafał Miłecki wrote:
> On 3 January 2016 at 10:36, Arend van Spriel wrote:
>> On 02-01-16 12:21, SF Markus Elfring wrote:
Did you look at the resulting assembly code for different target
architectures?
>>>
>>> Not yet. - Which execution system
On 3 January 2016 at 10:36, Arend van Spriel wrote:
> On 02-01-16 12:21, SF Markus Elfring wrote:
>>> Did you look at the resulting assembly code for different target
>>> architectures?
>>
>> Not yet. - Which execution system variants would you recommend for
>> further comparisons?
>
> Guess
>>> What the patch tries to do is avoid the extra 'if (err)'.
>>
>> Yes. - I propose to look at related consequences together with the usage
>> of a popular short jump label once more.
>
> When I read a subject saying "Better exception handling" it sounds like
> a functional improvement. Your
On 02-01-16 12:21, SF Markus Elfring wrote:
>> I have never seen much evolution going on in this area.
>
> I can get an other impression from a specific document for example.
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/Documentation/CodingStyle
>
>
>> What the patch
On 02-01-16 12:21, SF Markus Elfring wrote:
>> I have never seen much evolution going on in this area.
>
> I can get an other impression from a specific document for example.
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/Documentation/CodingStyle
>
>
>> What the patch
On 3 January 2016 at 10:36, Arend van Spriel wrote:
> On 02-01-16 12:21, SF Markus Elfring wrote:
>>> Did you look at the resulting assembly code for different target
>>> architectures?
>>
>> Not yet. - Which execution system variants would you recommend for
>> further
>>> What the patch tries to do is avoid the extra 'if (err)'.
>>
>> Yes. - I propose to look at related consequences together with the usage
>> of a popular short jump label once more.
>
> When I read a subject saying "Better exception handling" it sounds like
> a functional improvement. Your
> I have never seen much evolution going on in this area.
I can get an other impression from a specific document for example.
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/Documentation/CodingStyle
> What the patch tries to do is avoid the extra 'if (err)'.
Yes. - I
On 02-01-16 10:08, SF Markus Elfring wrote:
>>> I assume that a software development taste can evolve, can't it?
>>
>> So far, you have gotten several down votes for this kind of change,
>
> I am curious when more contributors will share corresponding opinions.
Let's burn some cycles on this
>> I assume that a software development taste can evolve, can't it?
>
> So far, you have gotten several down votes for this kind of change,
I am curious when more contributors will share corresponding opinions.
> and no enthusiasm.
How many software designers and developers can become
On Sat, 2 Jan 2016, SF Markus Elfring wrote:
> >> Move the jump label directly before the desired log statement
> >> so that the variable "err" will not be checked once more
> >> after it was determined that a function call failed.
> >> Use the identifier "report_failure" instead of the label
>> Move the jump label directly before the desired log statement
>> so that the variable "err" will not be checked once more
>> after it was determined that a function call failed.
>> Use the identifier "report_failure" instead of the label "err".
>
>Why?
I suggest to reconsider the places
>> Move the jump label directly before the desired log statement
>> so that the variable "err" will not be checked once more
>> after it was determined that a function call failed.
>> Use the identifier "report_failure" instead of the label "err".
>
>Why?
I suggest to reconsider the places
> I have never seen much evolution going on in this area.
I can get an other impression from a specific document for example.
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/Documentation/CodingStyle
> What the patch tries to do is avoid the extra 'if (err)'.
Yes. - I
On 02-01-16 10:08, SF Markus Elfring wrote:
>>> I assume that a software development taste can evolve, can't it?
>>
>> So far, you have gotten several down votes for this kind of change,
>
> I am curious when more contributors will share corresponding opinions.
Let's burn some cycles on this
On Sat, 2 Jan 2016, SF Markus Elfring wrote:
> >> Move the jump label directly before the desired log statement
> >> so that the variable "err" will not be checked once more
> >> after it was determined that a function call failed.
> >> Use the identifier "report_failure" instead of the label
>> I assume that a software development taste can evolve, can't it?
>
> So far, you have gotten several down votes for this kind of change,
I am curious when more contributors will share corresponding opinions.
> and no enthusiasm.
How many software designers and developers can become
Hello
On 1/2/2016 12:33 AM, SF Markus Elfring wrote:
From: Markus Elfring
Date: Fri, 1 Jan 2016 22:27:20 +0100
This issue was detected by using the Coccinelle software.
Move the jump label directly before the desired log statement
so that the variable "err" will not be checked once more
On Fri, 1 Jan 2016, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Fri, 1 Jan 2016 22:27:20 +0100
>
> This issue was detected by using the Coccinelle software.
>
> Move the jump label directly before the desired log statement
> so that the variable "err" will not be checked once
From: Markus Elfring
Date: Fri, 1 Jan 2016 22:27:20 +0100
This issue was detected by using the Coccinelle software.
Move the jump label directly before the desired log statement
so that the variable "err" will not be checked once more
after it was determined that a function call failed.
Use the
On Fri, 1 Jan 2016, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Fri, 1 Jan 2016 22:27:20 +0100
>
> This issue was detected by using the Coccinelle software.
>
> Move the jump label directly before the desired log statement
> so that the variable
Hello
On 1/2/2016 12:33 AM, SF Markus Elfring wrote:
From: Markus Elfring
Date: Fri, 1 Jan 2016 22:27:20 +0100
This issue was detected by using the Coccinelle software.
Move the jump label directly before the desired log statement
so that the variable "err"
From: Markus Elfring
Date: Fri, 1 Jan 2016 22:27:20 +0100
This issue was detected by using the Coccinelle software.
Move the jump label directly before the desired log statement
so that the variable "err" will not be checked once more
after it was determined that
28 matches
Mail list logo