include/list.h

[Keith Packard]

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. Plus, the list macros aren't even
type safe, and the appear to encourage type-unsafe coding styles.

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

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

 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.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100610/db4e4b91/attachment.pgp>