[PATCH] include/c: re-add type checking in container_of()

[PATCH] include/c: re-add type checking in container_of()

[Ruediger Meier]

From: Ruediger Meier <ruediger.meier@ga-group.nl>

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.

Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
---
 include/c.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/c.h b/include/c.h
index 8b2a2d19a..f1e329819 100644
--- a/include/c.h
+++ b/include/c.h
@@ -147,8 +147,8 @@
  */
 #ifndef container_of
 #define container_of(ptr, type, member) __extension__ ({	\
-	void *__mptr = (void *)(ptr);				\
-	((type *)(__mptr - offsetof(type, member))); })
+	const __typeof__( ((type *)0)->member ) *__mptr = (ptr); \
+	(type *)( (char *)__mptr - offsetof(type,member) );})
 #endif
 
 #ifndef HAVE_PROGRAM_INVOCATION_SHORT_NAME
-- 
2.13.7

Re: [PATCH] include/c: re-add type checking in container_of()

[Karel Zak]

On Sun, Dec 02, 2018 at 07:23:45PM +0100, Ruediger Meier wrote:
> From: Ruediger Meier <ruediger.meier@ga-group.nl>
> 
> 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 ;-)

Applied, thanks!

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: [PATCH] include/c: re-add type checking in container_of()

[Ruediger Meier]

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@ga-group.nl>
> >
> > 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

Re: [PATCH] include/c: re-add type checking in container_of()

[Ruediger Meier]

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@ga-group.nl>
> >
> > 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 ;-)


BTW this is a nice webtool where you can see the issues quickly:

https://godbolt.org/z/Z2XvPc

cu,
Rudi