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 rec
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 x86{
>>> 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 chan
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
> 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 propo
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 wh
>> 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 enthusia
