Missing LIST_PREV() ?
Julian Elischer
julian at elischer.org
Tue May 8 19:48:23 UTC 2007
Hans Petter Selasky wrote:
> On Tuesday 08 May 2007 20:45, Julian Elischer wrote:
>> John Baldwin wrote:
>>> On Monday 07 May 2007 04:25:18 pm Giorgos Keramidas wrote:
>>>> with other compilers.
>>> This can be fixed by passing the type as an argument which is what
>>> TAILQ_PREV() does:
>>>
>>> #define TAILQ_PREV(elm, headname, field) \
>>> (*(((struct headname *)((elm)->field.tqe_prev))->tqh_last))
>>>
>>> I'm not sure how portable offsetof() would be though. In general if you
>>> want this feature, you should just use a TAILQ though. TAILQ_ENTRY() is
>>> the same size as a LIST_ENTRY(), it just adds one more pointer to the
>>> HEAD structure. It is also specifically designed to make TAILQ_PREV()
>>> work w/o needing the offsetof() hack.
>> I agree with this.. that's why we have the different types.
>> The suggested change in ingenious but I don't know how portable it is..
>
> I suggested the following at hacker's:
>
> #define LIST_PREV(head,elm,field,type) \
> (((elm) == LIST_FIRST(head)) ? ((struct type *)0) : \
> ((struct type *)(((uint8_t *)((elm)->field.le_prev)) - \
> ((uint8_t *)&LIST_NEXT((struct type *)0,field)))))
>
> What do you think?
>
> --HPS
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
I think I'd rather use offsetof() with a #ifdef offsetof around it.
and a comment saying that if you are using this you probably should
be using a TAILQ.
The question is "should we, just because we can?"
More information about the freebsd-arch
mailing list