why add the result of check_type in container_of

why add the result of check_type in container_of

[Yubin Ruan]

Hi,

I notice that in the implementation of container_of(), the resulting pointer
will be advanced by 1 if types mismatch:

#define container_of(member_ptr, containing_type, member)   \
	 ((containing_type *)                                   \
	  ((char *)(member_ptr)                                 \
	   - container_off(containing_type, member))            \
	  + check_types_match(*(member_ptr), ((containing_type *)0)->member))

where check_types_match() is defined as 

#define check_types_match(expr1, expr2)		\
	((typeof(expr1) *)0 != (typeof(expr2) *)0)

which will return 1 if types mismatch.

IMO, advancing the wrong pointer (resulting from mismatch types) by 1 will
only make things worse, and users usually only get garbage results and will not
be aware of the type-mismatch bug. Wouldn't it be better to throw an building
error/warning for that?

Yubin
_______________________________________________
ccan mailing list
ccan@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/ccan

Re: why add the result of check_type in container_of

[David Gibson]

[-- Attachment #1.1: Type: text/plain, Size: 1465 bytes --]

On Mon, Mar 12, 2018 at 11:19:39AM +0800, Yubin Ruan wrote:
> Hi,
> 
> I notice that in the implementation of container_of(), the resulting pointer
> will be advanced by 1 if types mismatch:
> 
> #define container_of(member_ptr, containing_type, member)   \
> 	 ((containing_type *)                                   \
> 	  ((char *)(member_ptr)                                 \
> 	   - container_off(containing_type, member))            \
> 	  + check_types_match(*(member_ptr), ((containing_type *)0)->member))
> 
> where check_types_match() is defined as 
> 
> #define check_types_match(expr1, expr2)		\
> 	((typeof(expr1) *)0 != (typeof(expr2) *)0)
> 
> which will return 1 if types mismatch.

No.. it won't, it will have a type error.  That's not typeof(x) ==
typeof(y), which isn't valid C (or gcc) in any case.  It's checking if
NULL (0) cast to the first pointer type equals NULL cast to the second
pointer type.  If the types mismatch, there will be a type error.
 
> IMO, advancing the wrong pointer (resulting from mismatch types) by 1 will
> only make things worse, and users usually only get garbage results and will not
> be aware of the type-mismatch bug. Wouldn't it be better to throw an building
> error/warning for that?

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
ccan mailing list
ccan@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/ccan