All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Christoph Hellwig <hch@lst.de>
Cc: Marcin Slusarz <marcin.slusarz@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 2/6] ERR_PTR: add ERR_OR_0_PTR
Date: Mon, 19 May 2008 07:33:55 +0100	[thread overview]
Message-ID: <20080519063355.GA13907@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20080519055504.GB14902@lst.de>

On Mon, May 19, 2008 at 07:55:04AM +0200, Christoph Hellwig wrote:
> On Mon, May 19, 2008 at 12:01:07AM +0200, Marcin Slusarz wrote:
> > Some codepaths call ERR_PTR with possibly 0 argument, which is not
> > a valid errno and rely on conversion from 0 to NULL pointer.
> > Add ERR_OR_0_PTR function which accepts errnos and 0 as an argument.
> 
> Sorry, no.  ERR_PTR(0) is perfectly valid, you just don't want to return
> the actualy value.  E.g. we have a common idiom of:
> 
> 	some_ptr = ERR_PTR(err);
> 	if (IS_ERR(some_ptr))
> 		goto out_handle_err;
> 
> and obsfucating this with new syntactic sugar is not a good idea.

Um... Could somebody explain WTF is wrong with declaring that ERR_PTR(0)
is NULL?  Sure, if we run into a target where converting non-constant
integer with value zero to void * does not result in null pointer, we'll
need to adjust ERR_PTR().  So.  Fscking.  What?
	a) it's not a lot of adjustment, to start with
	b) any such target will require much more work on porting anyway;
this part will be trivial.

  reply	other threads:[~2008-05-19  6:34 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-11 20:12 [PATCH] let ERR_PTR BUILD_BUG_ON when we know its argument is not a valid errno Marcin Slusarz
2008-05-12 23:38 ` Andrew Morton
2008-05-13 20:18   ` Marcin Slusarz
2008-05-18 21:56     ` [PATCH 0/6] Sanity checks for ERR_PTR argument Marcin Slusarz
2008-05-18 21:56     ` [PATCH 1/6] ERR_PTR: if errno value is known at compile time, make sure it's valid Marcin Slusarz
2008-05-19  6:38       ` Alexey Dobriyan
2008-05-22 16:03         ` Marcin Slusarz
2008-05-18 22:01     ` [PATCH 2/6] ERR_PTR: add ERR_OR_0_PTR Marcin Slusarz
2008-05-18 23:04       ` Johannes Weiner
2008-05-19  5:55       ` Christoph Hellwig
2008-05-19  6:33         ` Al Viro [this message]
2008-05-18 22:01     ` [PATCH 3/6] vfs: open_exec cleanup Marcin Slusarz
2008-05-19  5:53       ` Christoph Hellwig
2008-05-22 15:57         ` Marcin Slusarz
2008-05-18 22:03     ` [PATCH 4/6] procfs: switch ERR_PTR to ERR_OR_0_PTR when "error" might be 0 Marcin Slusarz
2008-05-18 22:03     ` [PATCH 5/6] vfs: fix ERR_PTR abuse in generic_readlink Marcin Slusarz
2008-05-18 22:04     ` [PATCH 6/6] ERR_PTR: warn when ERR_PTR parameter is not errno value Marcin Slusarz
2008-05-18 23:13       ` Johannes Weiner
2008-05-19  6:43         ` Alexey Dobriyan
2008-05-19 12:11           ` Johannes Weiner
2008-05-22 16:08             ` Marcin Slusarz

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=20080519063355.GA13907@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcin.slusarz@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 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.