Messages in this thread |  | | | Date | Tue, 23 Jul 2002 18:58:52 -0400 | | From | "Kevin O'Connor" <> | | Subject | Re: PATCH: type safe(r) list_entry repacement: generic_out_cast |
| |
On Tue, Jul 23, 2002 at 09:28:26PM +1000, Neil Brown wrote: > However it doesn't do any type checking on the pointer, and you can > give it a pointer to something else... just as I did in line 850 of > md/md.c :-(
Hi Neil,
I've experienced the same problem with some of my own code. I came up with the following macro to help solve the problem:
/* Given a pointer to a member of a struct, return a pointer to the struct itself. */ #define BackPtr(ptr, type, member) ({ \ typeof( ((type *)0)->member ) *__mptr = (ptr); \ ((type *)( (char *)__mptr - (unsigned long)(&((type *)0)->member) ));}) > So I thought I would add some type checking to list_entry so that > you have to pass it a "struct list_head *", but I then discovered that > lots of places are using list_entry to do creative casting on > all sorts of other things like inodes embedded in bigger structures > and so on. > > So... I have created "generic_out_cast" which is like the old > list_entry but with an extra type arguement.
I don't think this is necessary. The compiler can get this information from the type/member parameters and the typeof() call.
> Why "out_cast"???
Ugh.. I had a similar naming dilemma - I choose BackPtr (because the macro causes a negative pointer offset).
-Kevin
-- ------------------------------------------------------------------------ | Kevin O'Connor "BTW, IMHO we need a FAQ for | | kevin@koconnor.net 'IMHO', 'FAQ', 'BTW', etc. !" | ------------------------------------------------------------------------ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |