[PATCH] include: purge foo(int /*bar*/) function declarations.

[Peter Hutterer]

On 6/01/11 19:25 , Mark Kettenis wrote:
>> Date: Thu, 6 Jan 2011 14:29:59 +1000
>> From: Peter Hutterer<peter.hutterer at who-t.net>
>>
>> because, really, comments should be for comments.
>
> Not sure this is a good idea, at least not in public headers.

note that we're not talking about about libX11 headers here, we're just 
talking about server headers. they are used in extensions and drivers, 
not elsewhere AFAICT. we've broken much worse in the past, though we 
should probably hold off this until the 1.11 merge window starts, just 
in case.

also, these are mostly ancient headers that have been copied in style in 
the past (hence why some newer functions use the same convention). most 
headers that originated newer newer don't use this convention at all. so 
if anything, this would just bring it in line with the more modern parts 
of the server.

> The problem is that if you have
>
> extern void foo(int bar);
>
> and for some reason bar is #defined to something nontrivial, you'll
> get compilation failures.  Another nice one is:
>
> extern void foo(int class);
>
> which won't compile if you include the header file from C++.  And
> before you say that this isn't likely to happen, you have one in your
> diff:
>
>   typedef    void (* QueryBestSizeProcPtr)(
> -	int /*class*/,
> -	unsigned short * /*pwidth*/,
> -	unsigned short * /*pheight*/,
> -	ScreenPtr /*pScreen*/);
> +	int class,
> +	unsigned short * pwidth,
> +	unsigned short * pheight,
> +	ScreenPtr pScreen);
>
> Now glibc solves the problem by prepending two underscores to the
> argument names in its header files.  That works because POSIX
> explicitly says that the symbols prefixed with __ are "reserved for
> the system", and users are not supposed to define their own symbols.
> But while glibc can make a solid case for being part of "the system",
> I'm not quite so sure about Xorg.
>
> If you really, really want to get rid of these comments, simply omit
> them.  But I do think they are actually useful since they allow people
> to make some educated guess about what parameters to pass to the
> interface (and in what order) by just looking at the header file.

yeah, agreed. I'd rather leave the comments there than omit the 
parameter name.

> Also, please, please don't put a space on either side of '*' for
> pointer declarations (i.e. "void * p").  I know it is a matter of
> style, and therefore personal taste, but my brain is wired to
> recognise that as a multiplication operator.  Everybody knows you
> should use "void *p" in proper C code.

yeah, sorry, that was a regex problem, can be easily fixed up.

Cheers,
   Peter