On Monday 03 December 2018, Karel Zak wrote:
> On Sun, Dec 02, 2018 at 07:23:45PM +0100, Ruediger Meier wrote:
> > From: Ruediger Meier <ruediger.meier@xxxxxxxxxxx>
> >
> > This reverts parts of commit eb06d5d4, which seems to be based on
> > Linux kernel commit c7acec71. Unlike the original kernel patch we
> > did not add that even stronger type checking by using macro
> > BUILD_BUG_ON_MSG. So basically we removed a useful warning when
> > compiling such broken code:
> >
> > struct st {
> > int a;
> > char b;
> > };
> > struct st t = { .a = 1, .b = 2 };
> > struct st *x = container_of(&t.a, struct st, b);
> > printf("%p %p\n", (void *)&t, (void *)x);
> >
> > Moreover we also introduced a new compiler warning for intel/icc:
> > "arithmetic on pointer to void or function type"
> >
> > Let's just revert the update of container_of() because adding a
> > kernel-like BUILD_BUG_ON_MSG would be too much noise and also
> > problematic (see kernel commit c03567a8). Also note that the
> > original problem addressed by the kernel commit seems to be only
> > reproducible with gcc 4.9, not with any later gcc nor clang,icc.
> > Moreover, currently we have no such use-case in the UL sources
> > anyways.
>
> Interesting, I do not see any issue with list_entry(() now ;-)
Well, actually the macro would perfectly work as simple as this:
#define container_of(ptr, type, member) ( \
(type *)((char *)ptr - offsetof(type,member)) )
All additional stuff is only to get some warnings if programmers are
using the macro wrongly. Unfortunately also some false positive
warnings. That was and is still the only problem here ...
overengineering ;)
cu,
Rudi
