[ccan] why add the result of check_type in container_of

[David Gibson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/ccan/attachments/20180314/3577fd59/attachment.sig>