lkml.org 
[lkml]   [2016]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: CodingStyle: Clarify and complete chapter 7
From
Date
>>> A common type of bug to be aware of is "one err bugs" which look like this:
>>>
>>> - err:
>>> + err:
>>> kfree(foo->bar);
>>> kfree(foo);
>>> return ret;
>>>
>>> The bug in this code is that on some exit paths "foo" is NULL. Normally the
>>
>> ...except that kfree() can handle null pointers just fine, so this isn't
>> actually a bug, right? Someday when somebody has time it would be good to
>> come up with a better example.
>
> But if foo is NULL,

An important condition …


> foo->bar is not NULL

I wonder about this information. Which run-time environment will provide
this behaviour?


> and so kfree will have a problem with it.

I find that the parameter evaluation will result in side effects
(because of a null pointer access) which are usually unwanted.
So the execution of this function call will eventually not start.


> So this is a bug.

How do you think about further software development possibilities to improve
corresponding exception handling?

How much can the selection of jump labels influence the software design?

Regards,
Markus

\
 
 \ /
  Last update: 2016-09-17 09:56    [W:0.037 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site