[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <945E314B-86E1-4DDE-9F8F-347A11C78393@mac.com>
Date: Wed, 4 Oct 2006 23:47:17 -0400
From: Kyle Moffett <mrmacman_g4@....com>
To: Andrew Morton <akpm@...l.org>
Cc: Matthew Wilcox <matthew@....cx>, linux-kernel@...r.kernel.org
Subject: Re: Must check what?
On Oct 04, 2006, at 15:43:10, Andrew Morton wrote:
> (Or we do
>
> return assert_zero_or_errno(ret);
>
> which is a bit ug, but gets us there)
I'm personally a big fan of:
typedef int kerr_t;
# define kreterr_t kerr_t __must_check
Then:
kreterr_t some_device_function(void *data)
{
kerr_t result;
if (!data)
return -EINVAL;
result = other_device_function(data + sizeof(struct foo));
[...]
return result;
}
You could even tag __bitwise on kerr_t except that wouldn't work
nicely with returning a negative error code. Is there any way to
tell sparse that:
-ESOMECODE => -((__force kerr_t)3)
is ok when kerr_t is a bitwise type, without allowing any other math
operations?
Alternatively you could:
#ifdef __KERNEL__
# define KENOENT ((__force kerr_t) -ENOENT)
# define KENOMEM ((__force kerr_t) -ENOMEM)
[...]
#endif
But that's a _lot_ of code churn for fairly minimal gain. It might
be easier just to patch sparse to add an errcode type attribute with
the desired behavior. There also might be some way to do it with
enums but I'm not familiar enough with the exact GCC behavior to
comment.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists