* why add the result of check_type in container_of
@ 2018-03-12 3:19 Yubin Ruan
2018-03-14 1:18 ` David Gibson
0 siblings, 1 reply; 2+ messages in thread
From: Yubin Ruan @ 2018-03-12 3:19 UTC (permalink / raw)
To: ccan
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: why add the result of check_type in container_of
2018-03-12 3:19 why add the result of check_type in container_of Yubin Ruan
@ 2018-03-14 1:18 ` David Gibson
0 siblings, 0 replies; 2+ messages in thread
From: David Gibson @ 2018-03-14 1:18 UTC (permalink / raw)
To: Yubin Ruan; +Cc: ccan
[-- 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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2018-03-14 1:18 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-12 3:19 why add the result of check_type in container_of Yubin Ruan
2018-03-14 1:18 ` David Gibson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.