Re: Fixing compiler warnings
On Mon, 2009-02-02 at 23:02 +0100, Tomas Carnecky wrote: -- 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. Yeah, those (and all like them) should come from include/ top level instead of hw/. There doesn't seem to be a sensible place already, so I nominate include/extinit.h as being obviously named. The other two function protos in extinit.h should move in the process. input.h probably? -- 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? Probably. I wouldn't worry too much about those warnings, the compiler will optimize the functions out for you, but would be nice to clean up. -- 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? We're not broadly assuming the existence of stdint.h yet. But we certainly should. If you felt like rewriting Xmd.h in terms of same... And then, yeah, uintptr_t all the way. 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'. This is an unfortunate bit of ABI. Not sure how to shut up the warnings in this case. -- 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 *'? In the symbol export list, yes. -- 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? 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. xf86IsSubsetOf() isn't used. Anywhere. And that's the only caller. Kill 'em with fire. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fixing compiler warnings
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 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Fixing compiler warnings
I've been trying to fix the compiler warnings that gcc generates when compiling the xserver source. 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. -- 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. tom ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
