Re: Fwd: Question about container_of macro.

["Manish Katiyar" <mkatiyar@xxxxxxxxx>]

On Jan 18, 2008 2:44 PM, Laurent Pinchart <laurent.pinchart@xxxxxxxxx> wrote:
>
> On Friday 18 January 2008 05:29, Manish Katiyar wrote:
> > On Jan 18, 2008 9:45 AM, Manish Katiyar <mkatiyar@xxxxxxxxx> wrote:
> > > Hi Laurent,
> > >
> > > On Jan 18, 2008 5:31 AM, Laurent Pinchart <laurent.pinchart@xxxxxxxxx>
> wrote:
> > > > On Thursday 17 January 2008, Alan Stern wrote:
> > > > > On Thu, 17 Jan 2008, Manish Katiyar wrote:
> > > > > > My question is instead of defining container_of as:
> > > > > >
> > > > > > #define container_of(ptr, type, member) ({ \
> > > > > >                 const typeof( ((type *)0)->member ) *__mptr =
> > > > > > (ptr); (type *)( (char *)__mptr - offsetof(type,member) );})
> > > > > >
> > > > > >
> > > > > > Why won't this simply work :
> > > > > >
> > > > > > #define container_of(ptr, type, member) ({ \
> > > > > >                         (type *)( (char *)(ptr) -
> > > > > > offsetof(type,member) );})
> > > > >
> > > > > Indeed, or even this:
> > > > >
> > > > > #define container_of(ptr, type, member) \
> > > > >                       ((type *) ((char *)(ptr) -
> > > > > offsetof(type,member)))
> > > >
> > > > If I'm not mistaken, that's because
> > > >
> > > > const typeof( ((type *)0)->member ) *__mptr = (ptr);
> > > >
> > > > will warn (or maybe even bail out ?) if ptr is not a pointer to a
> > > > variable of member's type.
> > >
> > > But even if ptr is not a variable of member's type, in the second line
> > > we are force typecasting it to char * and then subtracting. I guess it
> > > will not warn. I tried in a simple program and it doesn't shout.
> > > Below is the program
>
> That's why you need
>
> const typeof( ((type *)0)->member ) *__mptr = (ptr);
>
> in addition to
>
> (type *)( (char *)__mptr - offsetof(type,member) );
>
> otherwise you'll get no warning.
>

But again, keeping in mind that this macro is one of frequently used
macros in kernel code, i am not sure how much it is justified to
allocate a local variable every time and then removing it without any
significant purpose. If we are keeping it just to ensure some rare
warnings, I would say it is an overkill and probably we can get rid of
it.

Comments/ suggetions ??

Thanks

> Laurent Pinchart
>



-- 
Thanks & Regards,
********************************************
Manish Katiyar  ( http://mkatiyar.googlepages.com )
3rd Floor, Fair Winds Block
EGL Software Park
Off Intermediate Ring Road
Bangalore 560071, India
***********************************************

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-devel@xxxxxxxxxxxxxxxxxxxxx
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel