Fixing compiler warnings

[Peter Hutterer]

On Mon, Feb 02, 2009 at 11:02:57PM +0100, Tomas Carnecky wrote:
> I've been trying to fix the compiler warnings that gcc generates when 
> compiling the xserver source. 

Pushed all minus the two I commented on, and the sdksyms.sh patch. I don't
know whether that's the right thing to do, so I left it.
Thanks for the patches.

> I've been able to fix quite a few, but 
> there are still some left, which I don't know how to resolve. I have 14 
> patches for the xserver and two for libxtrans. I can post them either 
> individually or give you a link to my public repo from which you can 
> fetch, or give you a link to cgit so you can look at the commits with a 
> web browser. All patches except one of the libxtrans patches are just a 
> couple lines. But one is huge (94KB) because it touches much of the 
> libxtrans code.
> 
> However, there are a few warnings I was not able to fix, and some I 
> probably won't be fixing (the ones that come from fb/ -- a scary place 
> which is using lots of macros and other obfuscation techniques). That 
> leaves me with a handful of different types of warnings which should be 
> easy to fix, once I know what the preferred approach is. So let's start:
> 
> ----------------------------------------------------------------------
> bigreq.c:46: warning: no previous prototype for ‘BigReqExtensionInit’
> sync.c:2124: warning: no previous prototype for ‘SyncExtensionInit’
> xcmisc.c:59: warning: no previous prototype for ‘XCMiscExtensionInit’
> 
> These three extensions are the only ones that have no previous 
> prototype. It seems as the other extensions have their prototype from 
> hw/xfree86/dixmods/extmod/modinit.h. It seems a bit strange that Xext/ 
> modules include a file from hw/. But I'm not that familiar with the 
> dependencies so I'll leave it up to you to decide what's to be done here.

our header files are a bit of a mess, so if something looks really stupid,
chances are it might just be that.

> ----------------------------------------------------------------------
> glapitemp.h:1884: warning: ‘NoOp_dispatch_stub_339’ defined but not used
> (repeated many times for different stubs)
> 
> The file seems to have a mechanism to silence the compiler:
> /*
>   * This is just used to silence compiler warnings.
>   * We list the functions which are not otherwise used.
>   */
> 
> Maybe the gl_apitemp.py scripts needs to be updated and the file 
> regenerated?
> 
> ----------------------------------------------------------------------
> warning: cast to pointer from integer of different size
> warning: cast from function call of type ‘pointer’ to non-matching type 
> ‘long unsigned int’
> 
> This is because the code casts integers to pointers and back. Most of 
> the time the code just wants to save an int in the private data, and 
> uses something along these lines:
> 
>    int i;
>    dixSetPrivate(&devPrivates, myKey, (pointer) i);
>    i = dixGetPrivate(&devPrivates, myKey);
> 
> Should the code use (u)intptr_t in these cases?
> 
> In three cases the warning is about code in hw/xfree86/dri/dri.c casting 
> a void pointer to drm_handle_t which is 'unsigned int'.
> 
> ----------------------------------------------------------------------
> sdksyms.c:1056: warning: initialization discards qualifiers from pointer 
> target type
> 
> It seems because isItTimeToYield is declared volatile? Is it OK to 
> explicitly cast that symbol to 'void *'?
> 
> ----------------------------------------------------------------------
> Finally some warnings about deprecated functions. I don't think there's 
> anything that can be done with it except eventually removing the 
> functions, right?
> 
> ----------------------------------------------------------------------
> One warning in xf86Bus.c:x_isSubsetOf() which I reported in an earlier 
> mail. Maybe nobody cares about the code anymore. It hasn't been touched 
> since the initial import.

Cheers,
  Peter