daniel at fooishbar.org
Fri Jun 11 07:07:08 PDT 2010
On Fri, Jun 11, 2010 at 06:50:27AM -0700, Dan Nicholson wrote:
> On Thu, Jun 10, 2010 at 10:13 PM, Keith Packard <keithp at keithp.com> wrote:
> > Argh! A recent commit to the xf86 config parsing code added "list.h" to
> > xf86Parser.h, which is included by drivers to look stuff up. Because of
> > this, the intel driver no longer builds against master (would that the
> > drivers were in the server tree...). I have an RC1 tar file sitting here
> > and decided that I really should be running those bits before pushing it
> > out, and I really think I should at least try running it first.
> > To my mind, list.h really isn't needed in xf86Parser -- list elements
> > are only ever added to the head and then the whole list freed at once.
> > Here's an open coded replacement; shorter and has no casts.
> I want to use nice macros like list_for_each_entry. Why _wouldn't_ I
> use the generic one from list.h? Isn't that the entire reason why
> list.h was added? Sure, this is a simple singly-linked list, but the
> point is that I don't want to open code it again. Why was list.h added
> if not to use the thing?
This man speaks for me.
PS: If familiarity is the problem, then removing usage isn't going to
fix anything, only, er, make it worse.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the xorg-devel