Re: [PATCH v2 10/19] introduce container_of macro
- From
- Eric Wong <e@80x24.org>
- Date
- Sep 30, 2019, 10:39 UTC
- Message-ID
- <20190930103948.GA29474@dcvr>
- In-Reply-To
- <059c05bb-685a-7933-55ff-f18ed271ac3a@gmail.com>
Derrick Stolee <stolee@gmail.com> wrote:
Show 17 quoted lines
> On 9/23/2019 9:03 PM, Eric Wong wrote: > > This macro is popular within the Linux kernel for supporting > > intrusive data structures such as linked lists, red-black trees, > > and chained hash tables while allowing the compiler to do > > type checking. > > > > I intend to use this to remove the limitation of "hashmap_entry" > > being location-dependent and to allow more compile-time type > > checking. > > nit: I don't know why the first-person singular language caused > me to stumble during this message. Perhaps the following rewrite > would convey the same information: > > Later patches will use container_of() to remove the limitation > of "hashmap_entry" being location-dependent. This will complete > the transition to compile-time type checking for the hashmap API.
Agreed. Thanks.
Show 7 quoted lines
> > This macro already exists in our source as "list_entry" in > > list.h and making "list_entry" an alias to "container_of" > > as the Linux kernel has done is a possibility. > > If it is the same code, then I would prefer you do this conversion > now so we can see that equivalence in the patch AND we know that > existing code will test it.
One problem is I'm not sure if list.h should have an #include for git-compat-util.h, since list.h comes from an outside source....