Hi Chris,
On 12 July 2017 at 06:29, Christopher Li <sparse@xxxxxxxxxxx> wrote:
> On Tue, Jul 11, 2017 at 2:04 PM, Dibyendu Majumdar
> <mobile@xxxxxxxxxxxxxxx> wrote:
>> I think that duplicating a list because that list is being modified is
>> quite a sensible thing to do. My only suggestion would be that perhaps
>> you could have a dup() step that is separate so that you can use the
>> normal iterator macro after duplicating.
>
> So are you suggesting some thing like this:
>
> struct ptr_list *dup_list = NULL:
> concat_ptr_list(orign_list, &dup_list);
> FOR_EACH_PTR(dup_list, ptr) {
> ...
> } END_FOR_EACH_PTR(ptr);
> free_ptr_list(dup_list);
>
> I think that should work. But it come with a price
> allocating and freeing the list (otherwise it is a memory leak).
Yes that is what I meant. This is a typical solution to this type of problem.
>
> Also run slightly slower. My current way will only duplicate
> the list struct one at a time. It never duplicate the full list.
> It has fixed memory usage, no allocating, no duplicate of
> the ->next and ->prev pointer.
>
Okay - but is your approach generic enough? What if there was a split
in the node that you copied? I don't have a full understanding but it
appears to be a very specific solution rather than a general one.
> So what macro do you have in mind? I think any thing modify
> the duplicate list does not make sense.
>
> On thing I can do is rename the __list into __orig, then rename
> __dup into __list. Then most of the list macro using __list should
> work. It also means I have to use END_FOR_EACH_PTR_DUP()
> as well.
>
I was just saying that you can use the standard /existing iterator
macros once you have duplicated the list.
Regards
Dibyendu
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
