From: David Gibson <david@gibson.dropbear.id.au>
To: Yubin Ruan <ablacktshirt@gmail.com>
Cc: ccan@lists.ozlabs.org
Subject: Re: why add the result of check_type in container_of
Date: Wed, 14 Mar 2018 12:18:49 +1100 [thread overview]
Message-ID: <20180314011849.GF4182@umbus.fritz.box> (raw)
In-Reply-To: <20180312031939.GA29780@HP>
[-- 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
prev parent reply other threads:[~2018-03-14 1:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180314011849.GF4182@umbus.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=ablacktshirt@gmail.com \
--cc=ccan@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.