include/list.h

[Peter Hutterer]

On Thu, Jun 10, 2010 at 11:04:20PM -0700, Keith Packard wrote:
> On Fri, 11 Jun 2010 15:24:47 +1000, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> 
> > isn't the whole point of the list macros that we don't have dozens of
> > different list implementations, all with their own bugs?
> > you're just moving the problem, not fixing it.
> 
> For a singly linked list which is only freed once, I'd have to say that
> the benefit of using the list macros is pretty weak. I must be old
> fashioned, but I find an open coded singly-linked list far easier to
> read than the list macros we've got. 

I don't like them (yet) because I can read open coded lists better than the
macros. Though I haven't looked at the macros much yet but the preprocessor
output is scary. what matters long-term though is that the list macros are
supposed to be reliable and consistent, avoiding all the bugs of forgetting
to update the next pointer, etc.
The point is, I shouldn't have to look at a list implementation ever again
when triaging bugs (other than checking the parameters).

> Plus, the list macros aren't even
> type safe, and the appear to encourage type-unsafe coding styles.

Can the macros be made type-safe then?

> But, the real issue is that we've taken over a very short bit of the C
> namespace in a server header file which is now part of the required
> driver interface. And this causes existing code to fail to compile (the
> intel driver) as that is also providing this very same set of macros.
> 
> A couple of possible solutions:
> 
>  1) Promise to never expose list.h in the server API. Seems unlikely to
>     stick forever; someday someone will come up with a more compelling
>     use case than this one.
>     
>  2) change the names inside the server's 'list.h' file. That doesn't
>     appeal to me very much; non-standard names for standard macros
>     looks an awful lot like xalloc

it's not the same. xalloc was a pointless wrapper for something libc
has provided for years. the list macros are defined by us and shipped by us.
if libc shipped the list macros that'd be great but since it doesn't we have
to make up our own. and prefixing to avoid namespace clashes seems to be in
order then.
since many X hackers are also kernel hackers having different names to the
kernel names might be beneficial if the two implementations differ.

>  3) public list.h in some separate place, release that and have both the
>     server and intel driver depend on that.

combining this with 2 might be worthwile though to avoid any future system
header issues.

>  4) fix the intel driver to check to see if the server provides list.h
>     and use that.
> 
> > fwiw, the xf86printMatchGroup and  xf86freeMatchGroup would be useful even
> > if we keep the list implementation, they're the main cleanup here.
> 
> Ok, so perhaps I cheated a bit :-)
> 
> I was a bit frustrated to have one of the commits I merged today
> prevent me from running the new server code though.

the last week I've been bisecting across double git stashes because of that.
my pity is limited ;)

Cheers,
  Peter