[PATCH:libxt] Fix missing const qualifier.

[Jeremy Huddleston]

Shouldn't non-const versions "just work" when passed into a function with const?  I don't understand why it's creating a warning, but const handles have always hexed me.  Should the prototype actually be using 'const char * const *' instead of 'const char **'?

Even if there is no way to get rid of the newly introduced warning, the change is correct.  I'd rather see the change persist.

Additionally, the change to libXt is correct regardless of whether or not it generates a warning with the broken libX11.

Reviewed-By: Jeremy Huddleston <jeremyhu at apple.com>


On Nov 25, 2010, at 14:30, Alan Coopersmith wrote:

> Julien Cristau wrote:
>> On Thu, Nov 25, 2010 at 18:54:55 +0100, Cyril Brulebois wrote:
>> 
>>> In libX11's c8701115, atom names argument to XInternAtoms were marked as
>>> const.
>>> 
>>> This fixes the build with CFLAGS="-Wall -Werror":
>>> |   CC     Selection.lo
>>> | cc1: warnings being treated as errors
>>> | Selection.c: In function ‘GetPropList’:
>>> | Selection.c:191: error: passing argument 2 of ‘XInternAtoms’ from incompatible pointer type
>>> | /home/kibi/xorg-build/include/X11/Xlib.h:1549: note: expected ‘const char **’ but argument is of type ‘char **’
>>> 
>>> Signed-off-by: Cyril Brulebois <kibi at debian.org>
>>> ---
>>> src/Selection.c |    2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>> 
>> Does this introduce a warning with old libX11?
> 
> Unfortunately, it seems the const char ** change to XInternAtoms means
> that either old code gets warnings with new libX11 headers or new code
> gets warnings with old libX11 headers.   I missed this when testing
> somehow and had been expecting it to silently accept non-const arguments
> as it does when we pass a char * to a function defining its arguments
> as const char *.
> 
> Of course, most applications are passing constant/literal strings to these
> functions, so declaring it const seems the right thing, but breaking -Werror
> builds that used to work is unfriendly.
> 
> Anyone have a good solution?   Or is it best to just revert the libX11 change?
> 
> -- 
> 	-Alan Coopersmith-        alan.coopersmith at oracle.com
> 	 Oracle Solaris Platform Engineering: X Window System
> 
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel