public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: SF Markus Elfring <elfring@users.sourceforge.net>
To: Mark D Rustad <mrustad@gmail.com>
Cc: Jonathan Corbet <corbet@lwn.net>, Jean Delvare <jdelvare@suse.de>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: CodingStyle: Clarify and complete chapter 7
Date: Mon, 15 Aug 2016 17:38:42 +0200	[thread overview]
Message-ID: <633ca313-25b3-a9fe-bbed-883ca0273905@users.sourceforge.net> (raw)
In-Reply-To: <C5FAE00A-12A3-4AE6-97BB-794EC00549AD@gmail.com>

>>> 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

      parent reply	other threads:[~2016-08-15 15:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-25 12:29 [PATCH] CodingStyle: Clarify and complete chapter 7 Jean Delvare
2016-08-14 18:30 ` Jonathan Corbet
2016-08-14 20:12   ` Mark D Rustad
2016-08-14 20:45     ` Jonathan Corbet
2016-08-15 15:38     ` SF Markus Elfring [this message]

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=633ca313-25b3-a9fe-bbed-883ca0273905@users.sourceforge.net \
    --to=elfring@users.sourceforge.net \
    --cc=corbet@lwn.net \
    --cc=jdelvare@suse.de \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mrustad@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox