All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] fs/eventpoll: error handling micro-cleanup
Date: Sun, 01 Oct 2006 12:30:20 -0400	[thread overview]
Message-ID: <451FED1C.60900@garzik.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0610010911231.21285@alien.or.mcafeemobile.com>

Davide Libenzi wrote:
> On Sun, 1 Oct 2006, Jeff Garzik wrote:
> 
>> Davide Libenzi wrote:
>>> On Sun, 1 Oct 2006, Jeff Garzik wrote:
>>>
>>>> While reviewing the 'may be used uninitialized' bogus gcc warnings,
>>>> I noticed that an error code assignment was only needed if an error had
>>>> actually occured.
>>> But that saved one line of code, and there are countless occurences in the
>>> kernel of such code pattern ;)
>> I'm not sure there are countless occurrences with PTR_ERR().  The line is
>> incorrect (but harmless) if inode is a valid pointer...
> 
> I just tried a `find /usr/src/linux-2.6.16/ -type f -exec grep -H -C 2 PTR_ERR {} \;`
> and looked at the cases where the error variable is assigned in any case 
> before the test. Same code pattern as, like:
> 
> error = -EFAULT;
> if (copy_from_user(...))
> 	goto kaboom;

No, that's quite different.  I'm talking about

	ptr = get_a_pointer_from_somewhere()
	error = PTR_ERR(ptr)

See the difference?  The error variable is directly assigned from a 
potentially-valid pointer.  Doing that is quite error prone, whereas
	error = -EFOO
is not.

	Jeff



  reply	other threads:[~2006-10-01 16:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-01 12:43 [PATCH] fs/eventpoll: error handling micro-cleanup Jeff Garzik
2006-10-01 16:04 ` Davide Libenzi
2006-10-01 16:08   ` Jeff Garzik
2006-10-01 16:19     ` Davide Libenzi
2006-10-01 16:30       ` Jeff Garzik [this message]
2006-10-01 16:41         ` Davide Libenzi
2006-10-01 17:28           ` Jeff Garzik
2006-10-01 18:58             ` Davide Libenzi

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=451FED1C.60900@garzik.org \
    --to=jeff@garzik.org \
    --cc=akpm@osdl.org \
    --cc=davidel@xmailserver.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.