On Tue, 20 Aug 2002, Daniel Phillips wrote:
> > +#define slist_add_front(_new, _head) \
> > +do { \
> > + _new->next = _head; \
> > + _head = _new->next; \
> > +} while (0)
>
> The second line is equivalent to _head = _head.
I see. Is there something we'll need to do? Or is it just for the day?
> > +#define slist_add(_new, _head) \
> > +do { \
> > + _new->next = _head->next; \
> > + _head->next = _new; \
> > +} while (0)
>
> I don't see the point of this. Why doesn't the caller just push_list onto
> head->next?
Because we still want to keep up the old list? If _head->next was NULL, no
matter, we've added. If not, we've just inserted.
> #define push_list(list, node) do { \
> typeof(list) *_LIST_ = &(list), _NODE_ = (node); \
> _NODE_->next = *_LIST_; \
> *_LIST_ = _NODE_; } while (0)
>
> #define pop_list(list) ({ \
> typeof(list) *_LIST_ = &(list), _NODE_ = *_LIST_; \
> *_LIST_ = (*_LIST_)->next; \
> _NODE_; })
I'd rather call them push_slist, pop_slist (or as above). Think of the
millions of innocent people mixing lists and lists...
> On the third hand, if somebody does that they probably need bad things
> to happen to them.
This is perfect evolution. You end up having better code-checking, and a
third hand.
> - How do we know gcc will successfully optimize these things to the
> same code you'd get if you simply wrote the two required assignments
> out in full? The local variables should disappear early in constant
> expression evaluation, but do they always?
We shall have a look at the assembler output.
> - We assume the link field is named 'next'.
Must be forced then. Is it really that bad?
> - They are ugly (but I don't care. If you need to feast your eyes on
> ugly, look at any pgtable.h)
We shall comment on them to reduce uglyness.
Summary:
- We shall do it
- We shall force it
- We shall consider using slist names.
Thunder
-- --./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .- --/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..- .- -/---/--/---/.-./.-./---/.--/.-.-.- --./.-/-.../.-./.././.-../.-.-.-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/